5.1.10-stable review
Subsystems (7)
Greg Kroah-Hartman
maintainercover 5.1.10-stable review
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-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-5.1.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.1.10-rc1
Amir Goldstein <[email protected]>
ovl: support stacked SEEK_HOLE/SEEK_DATA
Jiufei Xue <[email protected]>
ovl: check the capability before cred overridden
Greg Kroah-Hartman <[email protected]>
Revert "drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)"
Greg Kroah-Hartman <[email protected]>
Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"
Dennis Zhou <[email protected]>
percpu: do not search past bitmap when allocating an area
Andrey Smirnov <[email protected]>
gpio: vf610: Do not share irq_chip
Marek Vasut <[email protected]>
ARM: shmobile: porter: enable R-Car Gen2 regulator quirk
Takeshi Kihara <[email protected]>
soc: renesas: Identify R-Car M3-W ES1.3
Hans de Goede <[email protected]>
usb: typec: fusb302: Check vconn is off when we start toggling
Marek Szyprowski <[email protected]>
ARM: exynos: Fix undefined instruction during Exynos5422 resume
Phong Hoang <[email protected]>
pwm: Fix deadlock warning when removing PWM device
Krzysztof Kozlowski <[email protected]>
ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8 regulators on Arndale Octa
Sakari Ailus <[email protected]>
media: v4l2-fwnode: Defaults may not override endpoint configuration in firmware
Christoph Vogtländer <[email protected]>
pwm: tiehrpwm: Update shadow register for disabling PWMs
Andy Shevchenko <[email protected]>
dmaengine: idma64: Use actual device for DMA transfers
Christopher N Bednarz <[email protected]>
ice: Do not set LB_EN for prune switch rules
Yashaswini Raghuram Prathivadi Bhayankaram <[email protected]>
ice: Enable LAN_EN for the right recipes
Sven Eckelmann <[email protected]>
batman-adv: Adjust name for batadv_dat_send_data
Dafna Hirschfeld <[email protected]>
media: v4l2-ctrl: v4l2_ctrl_request_setup returns with error upon failure
Brett Creeley <[email protected]>
ice: Add missing case in print_link_msg for printing flow control
Tony Lindgren <[email protected]>
gpio: gpio-omap: limit errata 1.101 handling to wkup domain gpios only
Tony Lindgren <[email protected]>
gpio: gpio-omap: add check for off wake capable gpios
Bjorn Andersson <[email protected]>
arm64: dts: qcom: qcs404: Fix regulator supply names
Kangjie Lu <[email protected]>
PCI: xilinx: Check for __get_free_pages() failure
Paolo Valente <[email protected]>
block, bfq: increase idling for weight-raised queues
Kangjie Lu <[email protected]>
video: imsttfb: fix potential NULL pointer dereferences
Kangjie Lu <[email protected]>
video: hgafb: fix potential NULL pointer dereference
Jagan Teki <[email protected]>
Input: goodix - add GT5663 CTP support
Giridhar Malavali <[email protected]>
scsi: qla2xxx: Reset the FCF_ASYNC_{SENT|ACTIVE} flags
Marek Vasut <[email protected]>
PCI: rcar: Fix 64bit MSI message address handling
Kangjie Lu <[email protected]>
PCI: rcar: Fix a potential NULL pointer dereference
Kishon Vijay Abraham I <[email protected]>
PCI: dwc: Remove default MSI initialization for platform specific MSI chips
Peng Li <[email protected]>
net: hns3: return 0 and print warning when hit duplicate MAC
Chao Yu <[email protected]>
f2fs: fix potential recursive call when enabling data_flush
Sven Van Asbroeck <[email protected]>
power: supply: max14656: fix potential use-before-alloc
Junxiao Chang <[email protected]>
platform/x86: intel_pmc_ipc: adding error handling
Binbin Wu <[email protected]>
pinctrl: pinctrl-intel: move gpio suspend/resume to noirq phase
Kabir Sahane <[email protected]>
ARM: OMAP2+: pm33xx-core: Do not Turn OFF CEFUSE as PPA may be using it
Takashi Iwai <[email protected]>
ALSA: seq: Protect in-kernel ioctl calls with mutex
Nicholas Kazlauskas <[email protected]>
drm/amd/display: Use plane->color_space for dpp if specified
Anthony Koo <[email protected]>
drm/amd/display: disable link before changing link settings
Tyrel Datwyler <[email protected]>
PCI: rpadlpar: Fix leaked device_node references in add/remove paths
Andrey Smirnov <[email protected]>
ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA
Andrey Smirnov <[email protected]>
ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA
Andrey Smirnov <[email protected]>
ARM: dts: imx6ul: Specify IMX6UL_CLK_IPG as "ipg" clock to SDMA
Andrey Smirnov <[email protected]>
ARM: dts: imx7d: Specify IMX7D_CLK_IPG as "ipg" clock to SDMA
Andrey Smirnov <[email protected]>
ARM: dts: imx6sll: Specify IMX6SLL_CLK_IPG as "ipg" clock to SDMA
Andrey Smirnov <[email protected]>
ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA
Andrey Smirnov <[email protected]>
ARM: dts: imx53: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
Andrey Smirnov <[email protected]>
ARM: dts: imx50: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
Andrey Smirnov <[email protected]>
ARM: dts: imx51: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
Andrey Smirnov <[email protected]>
arm64: dts: imx8mq: Mark iomuxc_gpr as i.MX6Q compatible
Douglas Anderson <[email protected]>
soc: rockchip: Set the proper PWM for rk3288
Lu Baolu <[email protected]>
iommu/vt-d: Flush IOTLB for untrusted device in time
Bartosz Golaszewski <[email protected]>
usb: ohci-da8xx: disable the regulator if the overcurrent irq fired
Douglas Anderson <[email protected]>
clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288
Nathan Chancellor <[email protected]>
soc: mediatek: pwrap: Zero initialize rdata in pwrap_init_cipher
Kishon Vijay Abraham I <[email protected]>
PCI: keystone: Prevent ARM32 specific code to be compiled for ARM64
Kishon Vijay Abraham I <[email protected]>
PCI: keystone: Invoke phy_reset() API before enabling PHY
Enrico Granata <[email protected]>
platform/chrome: cros_ec_proto: check for NULL transfer function
Tony Lindgren <[email protected]>
power: supply: cpcap-battery: Fix signed counter sample register
Adam Ludkiewicz <[email protected]>
i40e: Queues are reserved despite "Invalid argument" error
Jon Hunter <[email protected]>
soc/tegra: pmc: Remove reset sysfs entries on error
Wenwen Wang <[email protected]>
x86/PCI: Fix PCI IRQ routing table memory leak
Mika Westerberg <[email protected]>
net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending
Wesley Sheng <[email protected]>
switchtec: Fix unintended mask of MRPC event
Will Deacon <[email protected]>
iommu/arm-smmu-v3: Don't disable SMMU in kdump kernel
Farhan Ali <[email protected]>
vfio: Fix WARNING "do not call blocking ops when !TASK_RUNNING"
Arnd Bergmann <[email protected]>
nfsd: avoid uninitialized variable warning
J. Bruce Fields <[email protected]>
nfsd: allow fh_want_write to be called twice
Kirill Smelkov <[email protected]>
fuse: retrieve: cap requested size to negotiated max_write
Chen-Yu Tsai <[email protected]>
nvmem: sunxi_sid: Support SID on A83T and H5
Jorge Ramirez-Ortiz <[email protected]>
nvmem: core: fix read buffer in place
Lu Baolu <[email protected]>
iommu/vt-d: Don't request page request irq under dmar_global_lock
Valentin Schneider <[email protected]>
arm64: defconfig: Update UFSHCD for Hi3660 soc
Nathan Fontenot <[email protected]>
powerpc/pseries: Track LMB nid instead of using device tree
Takashi Iwai <[email protected]>
ALSA: hda - Register irq handler after the chip initialization
Taehee Yoo <[email protected]>
netfilter: nf_flow_table: fix netdev refcnt leak
Taehee Yoo <[email protected]>
netfilter: nf_flow_table: check ttl value in flow offload data path
Keith Busch <[email protected]>
nvme-pci: shutdown on timeout during deletion
Keith Busch <[email protected]>
nvme-pci: unquiesce admin queue on shutdown
Kishon Vijay Abraham I <[email protected]>
PCI: designware-ep: Use aligned ATU window for raising MSI interrupts
Kishon Vijay Abraham I <[email protected]>
misc: pci_endpoint_test: Fix test_reg_bar to be updated in pci_endpoint_test
Greg Kurz <[email protected]>
vfio-pci/nvlink2: Fix potential VMA leak
Lu Baolu <[email protected]>
iommu/vt-d: Set intel_iommu_gfx_mapped correctly
Ming Lei <[email protected]>
blk-mq: move cancel of requeue_work into blk_mq_release
Vladimir Zapolskiy <[email protected]>
watchdog: fix compile time error of pretimeout governors
Georg Hofmann <[email protected]>
watchdog: imx2_wdt: Fix set_timeout for big timeout values
Florian Westphal <[email protected]>
netfilter: nf_tables: fix base chain stat rcu_dereference usage
Serge Semin <[email protected]>
mips: Make sure dt memory regions are valid
Jakub Jankowski <[email protected]>
netfilter: nf_conntrack_h323: restore boundary check correctness
Taehee Yoo <[email protected]>
netfilter: nf_flow_table: fix missing error check for rhashtable_insert_fast
Ludovic Barre <[email protected]>
mmc: mmci: Prevent polling for busy detection in IRQ context
Amir Goldstein <[email protected]>
ovl: do not generate duplicate fsnotify events for "fake" path
Andreas Schwab <[email protected]>
fbcon: Don't reset logo_shown when logo is currently shown
Jisheng Zhang <[email protected]>
PCI: dwc: Free MSI IRQ page in dw_pcie_free_msi()
Jisheng Zhang <[email protected]>
PCI: dwc: Free MSI in dw_pcie_host_init() error path
Maciej Żenczykowski <[email protected]>
uml: fix a boot splat wrt use of cpu_all_mask
YueHaibing <[email protected]>
configfs: fix possible use-after-free in configfs_register_group
John Sperbeck <[email protected]>
percpu: remove spurious lock dependency between percpu and sched
Eugen Hristev <[email protected]>
media: atmel: atmel-isc: fix asd memory allocation
Chao Yu <[email protected]>
f2fs: fix to do checksum even if inode page is uptodate
Chao Yu <[email protected]>
f2fs: fix to retrieve inline xattr space
Chao Yu <[email protected]>
f2fs: fix to avoid deadloop in foreground GC
Chao Yu <[email protected]>
f2fs: fix to do sanity check on valid block count of segment
Chao Yu <[email protected]>
f2fs: fix to avoid panic in dec_valid_node_count()
Chao Yu <[email protected]>
f2fs: fix to use inline space only if inline_xattr is enable
Chao Yu <[email protected]>
f2fs: fix to avoid panic in dec_valid_block_count()
Chao Yu <[email protected]>
f2fs: fix to clear dirty inode in error path of f2fs_iget()
Chao Yu <[email protected]>
f2fs: fix to do sanity check on free nid
Chao Yu <[email protected]>
f2fs: fix to avoid panic in f2fs_remove_inode_page()
Chao Yu <[email protected]>
f2fs: fix error path of recovery
Chao Yu <[email protected]>
f2fs: fix to avoid panic in f2fs_inplace_write_data()
Chao Yu <[email protected]>
f2fs: fix to avoid panic in do_recover_data()
Miroslav Lichvar <[email protected]>
ntp: Allow TAI-UTC offset to be set to zero
Fabien Dessenne <[email protected]>
mailbox: stm32-ipcc: check invalid irq
Martin Blumenstingl <[email protected]>
pwm: meson: Use the spin-lock only to protect register modifications
Michael Ellerman <[email protected]>
EDAC/mpc85xx: Prevent building as a module
Krzesimir Nowak <[email protected]>
bpf: fix undefined behavior in narrow load handling
Ben Skeggs <[email protected]>
drm/nouveau/kms/gv100-: fix spurious window immediate interlocks
Josh Poimboeuf <[email protected]>
objtool: Don't use ignore flag for fake jumps
Matt Redfearn <[email protected]>
drm/bridge: adv7511: Fix low refresh rate selection
Peteris Rudzusiks <[email protected]>
drm/nouveau: fix duplication of nv50_head_atom struct
Ben Skeggs <[email protected]>
drm/nouveau/kms/gf119-gp10x: push HeadSetControlOutputResource() mthd when encoders change
Stephane Eranian <[email protected]>
perf/x86/intel: Allow PEBS multi-entry in watermark mode
Tony Lindgren <[email protected]>
mfd: twl6040: Fix device init errors for ACCCTL register
Ben Skeggs <[email protected]>
drm/nouveau/disp/dp: respect sink limits when selecting failsafe link configuration
Binbin Wu <[email protected]>
mfd: intel-lpss: Set the device in reset state when init
Daniel Gomez <[email protected]>
mfd: tps65912-spi: Add missing of table registration
Amit Kucheria <[email protected]>
drivers: thermal: tsens: Don't print error message on -EPROBE_DEFER
Jiada Wang <[email protected]>
thermal: rcar_gen3_thermal: disable interrupt in .remove
Cyrill Gorcunov <[email protected]>
kernel/sys.c: prctl: fix false positive in validate_prctl_map()
Qian Cai <[email protected]>
mm/slab.c: fix an infinite loop in leaks_show()
Yue Hu <[email protected]>
mm/cma_debug.c: fix the break condition in cma_maxchunk_get()
Aneesh Kumar K.V <[email protected]>
mm: page_mkclean vs MADV_DONTNEED race
Yue Hu <[email protected]>
mm/cma.c: fix the bitmap status to show failed allocation reason
Baoquan He <[email protected]>
mm/memory_hotplug.c: fix the wrong usage of N_HIGH_MEMORY
Qian Cai <[email protected]>
mm/compaction.c: fix an undefined behaviour
Christoph Hellwig <[email protected]>
initramfs: free initrd memory if opening /initrd.image fails
Yue Hu <[email protected]>
mm/cma.c: fix crash on CMA allocation if bitmap allocation fails
Linxu Fang <[email protected]>
mem-hotplug: fix node spanned pages when we have a node with only ZONE_MOVABLE
David Hildenbrand <[email protected]>
mm/memory_hotplug: release memory resource after arch_remove_memory()
Mike Kravetz <[email protected]>
hugetlbfs: on restore reserve error path retain subpool reservation
Jérôme Glisse <[email protected]>
mm/hmm: select mmu notifier when selecting HMM
Arnd Bergmann <[email protected]>
ARM: prevent tracing IPI_CPU_BACKTRACE
Mike Rapoport <[email protected]>
mm/mprotect.c: fix compilation warning because of unused 'mm' variable
Guenter Roeck <[email protected]>
drm/pl111: Initialize clock spinlock early
Brian Masney <[email protected]>
drm/msm: correct attempted NULL pointer dereference in debugfs
Li Rongqing <[email protected]>
ipc: prevent lockup on alloc_msg and free_msg
Christian Brauner <[email protected]>
sysctl: return -EINVAL if val violates minmax
Hou Tao <[email protected]>
fs/fat/file.c: issue flush after the writeback of FAT
Kangjie Lu <[email protected]>
rapidio: fix a NULL pointer dereference when create_workqueue() fails
Jonas Karlman <[email protected]>
media: rockchip/vpu: Add missing dont_use_autosuspend() calls
Jonas Karlman <[email protected]>
media: rockchip/vpu: Fix/re-order probe-error/remove path
Dave Airlie <[email protected]>
Revert "drm: allow render capable master with DRM_AUTH ioctls"
-------------
Diffstat:
.../bindings/input/touchscreen/goodix.txt | 1 + Makefile | 4 +- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 + arch/arm/boot/dts/imx50.dtsi | 2 +- arch/arm/boot/dts/imx51.dtsi | 2 +- arch/arm/boot/dts/imx53.dtsi | 2 +- arch/arm/boot/dts/imx6qdl.dtsi | 2 +- arch/arm/boot/dts/imx6sl.dtsi | 2 +- arch/arm/boot/dts/imx6sll.dtsi | 2 +- arch/arm/boot/dts/imx6sx.dtsi | 2 +- arch/arm/boot/dts/imx6ul.dtsi | 2 +- arch/arm/boot/dts/imx7s.dtsi | 4 +- arch/arm/include/asm/hardirq.h | 1 + arch/arm/kernel/smp.c | 6 +- arch/arm/mach-exynos/suspend.c | 19 +++ arch/arm/mach-omap2/pm33xx-core.c | 8 +- arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 6 +- arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 28 ++--- arch/arm64/configs/defconfig | 6 +- arch/mips/kernel/prom.c | 14 ++- arch/powerpc/include/asm/drmem.h | 21 ++++ arch/powerpc/mm/drmem.c | 6 +- arch/powerpc/platforms/pseries/hotplug-memory.c | 17 ++- arch/um/kernel/time.c | 2 +- arch/x86/events/intel/core.c | 2 +- arch/x86/pci/irq.c | 10 +- block/bfq-iosched.c | 2 + block/blk-core.c | 1 - block/blk-mq.c | 2 + drivers/clk/rockchip/clk-rk3288.c | 11 ++ drivers/dma/idma64.c | 6 +- drivers/dma/idma64.h | 2 + drivers/edac/Kconfig | 4 +- drivers/gpio/gpio-omap.c | 53 +++++---- drivers/gpio/gpio-vf610.c | 26 ++--- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 9 ++ drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c | 6 +- .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +- drivers/gpu/drm/drm_ioctl.c | 20 +--- drivers/gpu/drm/msm/msm_gem.c | 3 +- drivers/gpu/drm/nouveau/Kconfig | 13 +-- drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 + drivers/gpu/drm/nouveau/dispnv50/head.c | 3 +- drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c | 1 + drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 7 +- drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 11 +- drivers/gpu/drm/pl111/pl111_display.c | 5 +- drivers/input/touchscreen/goodix.c | 2 + drivers/iommu/arm-smmu-v3.c | 10 +- drivers/iommu/intel-iommu.c | 19 ++- drivers/mailbox/stm32-ipcc.c | 13 ++- drivers/media/platform/atmel/atmel-isc.c | 8 +- drivers/media/v4l2-core/v4l2-ctrls.c | 18 +-- drivers/media/v4l2-core/v4l2-fwnode.c | 6 +- drivers/mfd/intel-lpss.c | 3 + drivers/mfd/tps65912-spi.c | 1 + drivers/mfd/twl6040.c | 13 ++- drivers/misc/pci_endpoint_test.c | 1 + drivers/mmc/host/mmci.c | 5 +- .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 7 +- drivers/net/ethernet/intel/i40e/i40e_main.c | 3 + drivers/net/ethernet/intel/ice/ice_main.c | 3 + drivers/net/ethernet/intel/ice/ice_switch.c | 36 ++++-- drivers/net/thunderbolt.c | 3 + drivers/nvme/host/pci.c | 10 +- drivers/nvmem/core.c | 15 ++- drivers/nvmem/sunxi_sid.c | 2 + drivers/pci/controller/dwc/pci-keystone.c | 8 ++ drivers/pci/controller/dwc/pcie-designware-ep.c | 7 +- drivers/pci/controller/dwc/pcie-designware-host.c | 45 ++++--- drivers/pci/controller/dwc/pcie-designware.h | 1 + drivers/pci/controller/pcie-rcar.c | 10 +- drivers/pci/controller/pcie-xilinx.c | 12 +- drivers/pci/hotplug/rpadlpar_core.c | 4 + drivers/pci/switch/switchtec.c | 3 +- drivers/pinctrl/intel/pinctrl-intel.c | 8 +- drivers/pinctrl/intel/pinctrl-intel.h | 11 +- drivers/platform/chrome/cros_ec_proto.c | 11 ++ drivers/platform/x86/intel_pmc_ipc.c | 6 +- drivers/power/supply/cpcap-battery.c | 11 +- drivers/power/supply/max14656_charger_detector.c | 14 +-- drivers/pwm/core.c | 10 +- drivers/pwm/pwm-meson.c | 25 ++-- drivers/pwm/pwm-tiehrpwm.c | 2 + drivers/pwm/sysfs.c | 14 +-- drivers/rapidio/rio_cm.c | 8 ++ drivers/scsi/qla2xxx/qla_gs.c | 3 + drivers/soc/mediatek/mtk-pmic-wrap.c | 2 +- drivers/soc/renesas/renesas-soc.c | 3 + drivers/soc/rockchip/grf.c | 2 + drivers/soc/tegra/pmc.c | 5 +- drivers/spi/spi-pxa2xx.c | 7 +- .../staging/media/rockchip/vpu/rockchip_vpu_drv.c | 10 +- drivers/thermal/qcom/tsens.c | 3 +- drivers/thermal/rcar_gen3_thermal.c | 3 + drivers/tty/serial/8250/8250_dw.c | 4 +- drivers/usb/host/ohci-da8xx.c | 22 +++- drivers/usb/typec/tcpm/fusb302.c | 2 + drivers/vfio/pci/vfio_pci_nvlink2.c | 2 + drivers/vfio/vfio.c | 30 ++--- drivers/video/fbdev/core/fbcon.c | 2 +- drivers/video/fbdev/hgafb.c | 2 + drivers/video/fbdev/imsttfb.c | 5 + drivers/watchdog/Kconfig | 1 + drivers/watchdog/imx2_wdt.c | 4 +- fs/configfs/dir.c | 17 ++- fs/dax.c | 2 +- fs/f2fs/checkpoint.c | 6 +- fs/f2fs/data.c | 3 +- fs/f2fs/f2fs.h | 30 ++++- fs/f2fs/gc.c | 1 + fs/f2fs/inline.c | 17 +++ fs/f2fs/inode.c | 5 +- fs/f2fs/node.c | 20 +++- fs/f2fs/recovery.c | 25 +++- fs/f2fs/segment.c | 9 +- fs/f2fs/segment.h | 3 +- fs/fat/file.c | 11 +- fs/fuse/dev.c | 2 +- fs/nfsd/nfs4xdr.c | 4 + fs/nfsd/vfs.h | 5 +- fs/overlayfs/file.c | 130 +++++++++++++++++---- include/linux/pwm.h | 5 - include/media/v4l2-ctrls.h | 2 +- include/net/bluetooth/hci_core.h | 3 - init/initramfs.c | 14 +-- ipc/mqueue.c | 10 +- ipc/msgutil.c | 6 + kernel/bpf/verifier.c | 2 +- kernel/sys.c | 2 +- kernel/sysctl.c | 6 +- kernel/time/ntp.c | 2 +- mm/Kconfig | 2 +- mm/cma.c | 23 ++-- mm/cma_debug.c | 2 +- mm/compaction.c | 4 +- mm/hugetlb.c | 21 +++- mm/memory_hotplug.c | 37 +++--- mm/mprotect.c | 5 +- mm/page_alloc.c | 6 +- mm/percpu.c | 9 +- mm/rmap.c | 2 +- mm/slab.c | 6 +- net/batman-adv/distributed-arp-table.c | 24 ++-- net/bluetooth/hci_conn.c | 8 -- net/netfilter/nf_conntrack_h323_asn1.c | 2 +- net/netfilter/nf_flow_table_core.c | 25 ++-- net/netfilter/nf_flow_table_ip.c | 6 + net/netfilter/nf_tables_api.c | 9 +- net/netfilter/nft_flow_offload.c | 1 + sound/core/seq/seq_clientmgr.c | 9 +- sound/pci/hda/hda_intel.c | 6 +- tools/objtool/check.c | 8 +- 156 files changed, 967 insertions(+), 461 deletions(-)
Greg Kroah-Hartman
maintainerPATCH 1/155 Revert "drm: allow render capable master with DRM_AUTH ioctls"
[ Upstream commit dbb92471674a48892f5e50779425e03388073ab9 ]
This reverts commit 8059add0478e29cb641936011a8fcc9ce9fd80be.
This commit while seemingly a good idea, breaks a radv check, for a node being master because something succeeds where it failed before now.
Apply the Linus rule, revert early and try again, we don't break userspace.
--- drivers/gpu/drm/drm_ioctl.c | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-)
drivers/gpu/drm/drm_ioctl.c +4 -16
@@ -508,13 +508,6 @@ int drm_version(struct drm_device *dev, void *data,return err; } -static inline bool -drm_render_driver_and_ioctl (const struct drm_device *dev,u32 flags) -{ -return drm_core_check_feature (dev,DRIVER_RENDER ) && - (flags &DRM_RENDER_ALLOW ); -} -/** * drm_ioctl_permit - Check ioctl permissions against caller *
@@ -529,19 +522,14 @@ drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags)*/ int drm_ioctl_permit (u32 flags,struct drm_file *file_priv) { -const struct drm_device *dev = file_priv->minor->dev; -/* ROOT_ONLY is only for CAP_SYS_ADMIN */ if (unlikely ((flags &DRM_ROOT_ONLY ) && !capable (CAP_SYS_ADMIN )))return -EACCES ; -/* AUTH is only for master ... */ -if (unlikely ((flags &DRM_AUTH ) &&drm_is_primary_client (file_priv))) { -/* authenticated ones, or render capable on DRM_RENDER_ALLOW. */ -if (!file_priv->authenticated && - !drm_render_driver_and_ioctl (dev, flags)) -return -EACCES ; - } +/* AUTH is only for authenticated or render client */ +if (unlikely ((flags &DRM_AUTH ) && !drm_is_render_client (file_priv) && + !file_priv->authenticated)) +return -EACCES ;/* MASTER is only for master or control clients */ if (unlikely((flags & DRM_MASTER) &&
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 2/155 media: rockchip/vpu: Fix/re-order probe-error/remove path
In reply to Greg Kroah-Hartman[ Upstream commit fc8670d1f72b746ff3a5fe441f1fca4c4dba0e6f ]
media_device_cleanup() and v4l2_m2m_unregister_media_controller() were missing in the probe error path.
While at it, re-order calls in the remove path to unregister/cleanup things in the reverse order they were initialized/registered.
--- drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c +5 -3
@@ -481,10 +481,12 @@ static int rockchip_vpu_probe(struct platform_device *pdev)return 0 ; err_video_dev_unreg:if (vpu->vfd_enc) { +v4l2_m2m_unregister_media_controller (vpu->m2m_dev);video_unregister_device (vpu->vfd_enc);video_device_release (vpu->vfd_enc); } err_m2m_rel: +media_device_cleanup (&vpu->mdev);v4l2_m2m_release (vpu->m2m_dev); err_v4l2_unreg:v4l2_device_unregister (&vpu->v4l2_dev);
@@ -501,13 +503,13 @@ static int rockchip_vpu_remove(struct platform_device *pdev)v4l2_info (&vpu->v4l2_dev,"Removing %s\n" , pdev->name);media_device_unregister (&vpu->mdev); -v4l2_m2m_unregister_media_controller (vpu->m2m_dev); -v4l2_m2m_release (vpu->m2m_dev); -media_device_cleanup (&vpu->mdev);if (vpu->vfd_enc) { +v4l2_m2m_unregister_media_controller (vpu->m2m_dev);video_unregister_device (vpu->vfd_enc);video_device_release (vpu->vfd_enc); } +media_device_cleanup (&vpu->mdev); +v4l2_m2m_release (vpu->m2m_dev);v4l2_device_unregister (&vpu->v4l2_dev);clk_bulk_unprepare (vpu->variant->num_clocks, vpu->clocks);pm_runtime_disable (vpu->dev);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 3/155 media: rockchip/vpu: Add missing dont_use_autosuspend() calls
In reply to Greg Kroah-Hartman[ Upstream commit 5c5b90f5cbad77dc15d8b5582efdb2e362bcd710 ]
Those calls are needed to restore a clean PM state when the probe fails or when the driver is unloaded such that future ->probe() calls can initialize runtime PM again.
--- drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c +2 -0
@@ -492,6 +492,7 @@ err_v4l2_unreg:v4l2_device_unregister (&vpu->v4l2_dev); err_clk_unprepare:clk_bulk_unprepare (vpu->variant->num_clocks, vpu->clocks); +pm_runtime_dont_use_autosuspend (vpu->dev);pm_runtime_disable (vpu->dev);return ret; }
@@ -512,6 +513,7 @@ static int rockchip_vpu_remove(struct platform_device *pdev)v4l2_m2m_release (vpu->m2m_dev);v4l2_device_unregister (&vpu->v4l2_dev);clk_bulk_unprepare (vpu->variant->num_clocks, vpu->clocks); +pm_runtime_dont_use_autosuspend (vpu->dev);pm_runtime_disable (vpu->dev);return 0 ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 4/155 rapidio: fix a NULL pointer dereference when create_workqueue() fails
In reply to Greg Kroah-Hartman[ Upstream commit 23015b22e47c5409620b1726a677d69e5cd032ba ]
In case create_workqueue fails, the fix releases resources and returns -ENOMEM to avoid NULL pointer dereference.
--- drivers/rapidio/rio_cm.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/rapidio/rio_cm.c +8 -0
@@ -2147,6 +2147,14 @@ static int riocm_add_mport(struct device *dev,mutex_init (&cm->rx_lock);riocm_rx_fill (cm,RIOCM_RX_RING_SIZE ); cm->rx_wq =create_workqueue (DRV_NAME "/rxq" ); +if (!cm->rx_wq) { +riocm_error ("failed to allocate IBMBOX_%d on %s" , + cmbox, mport->name); +rio_release_outb_mbox (mport, cmbox); +kfree (cm); +return -ENOMEM ; + } +INIT_WORK (&cm->rx_work, rio_ibmsg_handler); cm->tx_slot =0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 5/155 fs/fat/file.c: issue flush after the writeback of FAT
In reply to Greg Kroah-Hartman[ Upstream commit bd8309de0d60838eef6fb575b0c4c7e95841cf73 ]
fsync() needs to make sure the data & meta-data of file are persistent after the return of fsync(), even when a power-failure occurs later. In the case of fat-fs, the FAT belongs to the meta-data of file, so we need to issue a flush after the writeback of FAT instead before.
Also bail out early when any stage of fsync fails.
--- fs/fat/file.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-)
fs/fat/file.c +8 -3
@@ -193,12 +193,17 @@ static int fat_file_release(struct inode *inode, struct file *filp)int fat_file_fsync (struct file *filp,loff_t start,loff_t end,int datasync) {struct inode *inode = filp->f_mapping->host; -int res, err; +int err; + + err =__generic_file_fsync (filp, start, end, datasync); +if (err) +return err; - res =generic_file_fsync (filp, start, end, datasync); err =sync_mapping_buffers (MSDOS_SB (inode->i_sb)->fat_inode->i_mapping); +if (err) +return err; -return res ? res : err; +return blkdev_issue_flush (inode->i_sb->s_bdev,GFP_KERNEL ,NULL ); }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 6/155 sysctl: return -EINVAL if val violates minmax
In reply to Greg Kroah-Hartman[ Upstream commit e260ad01f0aa9e96b5386d5cd7184afd949dc457 ]
Currently when userspace gives us a values that overflow e.g. file-max and other callers of __do_proc_doulongvec_minmax() we simply ignore the new value and leave the current value untouched.
This can be problematic as it gives the illusion that the limit has indeed be bumped when in fact it failed. This commit makes sure to return EINVAL when an overflow is detected. Please note that this is a userspace facing change.
--- kernel/sysctl.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
kernel/sysctl.c +4 -2
@@ -2874,8 +2874,10 @@ static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, intif (neg)continue ; val = convmul * val / convdiv; -if ((min && val < *min) || (max && val > *max)) -continue ; +if ((min && val < *min) || (max && val > *max)) { + err = -EINVAL ; +break ; + } *i = val; }else { val = convdiv * (*i) / convmul;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 7/155 ipc: prevent lockup on alloc_msg and free_msg
In reply to Greg Kroah-Hartman[ Upstream commit d6a2946a88f524a47cc9b79279667137899db807 ]
msgctl10 of ltp triggers the following lockup When CONFIG_KASAN is enabled on large memory SMP systems, the pages initialization can take a long time, if msgctl10 requests a huge block memory, and it will block rcu scheduler, so release cpu actively.
After adding schedule() in free_msg, free_msg can not be called when holding spinlock, so adding msg to a tmp list, and free it out of spinlock
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-1 rcu_node (CPUs 16-31): P32505 rcu: Tasks blocked on level-1 rcu_node (CPUs 48-63): P34978 rcu: (detected by 11, t=35024 jiffies, g=44237529, q=16542267) msgctl10 R running task 21608 32505 2794 0x00000082 Call Trace: preempt_schedule_irq+0x4c/0xb0 retint_kernel+0x1b/0x2d RIP: 0010:__is_insn_slot_addr+0xfb/0x250 Code: 82 1d 00 48 8b 9b 90 00 00 00 4c 89 f7 49 c1 ee 03 e8 59 83 1d 00 48 b8 00 00 00 00 00 fc ff df 4c 39 eb 48 89 9d 58 ff ff ff <41> c6 04 06 f8 74 66 4c 8d 75 98 4c 89 f1 48 c1 e9 03 48 01 c8 48 RSP: 0018:ffff88bce041f758 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: dffffc0000000000 RBX: ffffffff8471bc50 RCX: ffffffff828a2a57 RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff88bce041f780 RBP: ffff88bce041f828 R08: ffffed15f3f4c5b3 R09: ffffed15f3f4c5b3 R10: 0000000000000001 R11: ffffed15f3f4c5b2 R12: 000000318aee9b73 R13: ffffffff8471bc50 R14: 1ffff1179c083ef0 R15: 1ffff1179c083eec kernel_text_address+0xc1/0x100 __kernel_text_address+0xe/0x30 unwind_get_return_address+0x2f/0x50 __save_stack_trace+0x92/0x100 create_object+0x380/0x650 __kmalloc+0x14c/0x2b0 load_msg+0x38/0x1a0 do_msgsnd+0x19e/0xcf0 do_syscall_64+0x117/0x400 entry_SYSCALL_64_after_hwframe+0x49/0xbe rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-1 rcu_node (CPUs 0-15): P32170 rcu: (detected by 14, t=35016 jiffies, g=44237525, q=12423063) msgctl10 R running task 21608 32170 32155 0x00000082 Call Trace: preempt_schedule_irq+0x4c/0xb0 retint_kernel+0x1b/0x2d RIP: 0010:lock_acquire+0x4d/0x340 Code: 48 81 ec c0 00 00 00 45 89 c6 4d 89 cf 48 8d 6c 24 20 48 89 3c 24 48 8d bb e4 0c 00 00 89 74 24 0c 48 c7 44 24 20 b3 8a b5 41 <48> c1 ed 03 48 c7 44 24 28 b4 25 18 84 48 c7 44 24 30 d0 54 7a 82 RSP: 0018:ffff88af83417738 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13 RAX: dffffc0000000000 RBX: ffff88bd335f3080 RCX: 0000000000000002 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88bd335f3d64 RBP: ffff88af83417758 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffffed13f3f745b2 R12: 0000000000000000 R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000 is_bpf_text_address+0x32/0xe0 kernel_text_address+0xec/0x100 __kernel_text_address+0xe/0x30 unwind_get_return_address+0x2f/0x50 __save_stack_trace+0x92/0x100 save_stack+0x32/0xb0 __kasan_slab_free+0x130/0x180 kfree+0xfa/0x2d0 free_msg+0x24/0x50 do_msgrcv+0x508/0xe60 do_syscall_64+0x117/0x400 entry_SYSCALL_64_after_hwframe+0x49/0xbe
Davidlohr said:
"So after releasing the lock, the msg rbtree/list is empty and new
calls will not see those in the newly populated tmp_msg list, and therefore they cannot access the delayed msg freeing pointers, which is good. Also the fact that the node_cache is now freed before the actual messages seems to be harmless as this is wanted for msg_insert() avoiding GFP_ATOMIC allocations, and after releasing the info->lock the thing is freed anyway so it should not change things"
--- ipc/mqueue.c | 10 ++++++++-- ipc/msgutil.c | 6 ++++++ 2 files changed, 14 insertions(+), 2 deletions(-)
ipc/mqueue.c +8 -2
@@ -436,7 +436,8 @@ static void mqueue_evict_inode(struct inode *inode)struct user_struct *user;unsigned long mq_bytes, mq_treesize;struct ipc_namespace *ipc_ns; -struct msg_msg *msg; +struct msg_msg *msg, *nmsg; +LIST_HEAD (tmp_msg);clear_inode (inode);
@@ -447,10 +448,15 @@ static void mqueue_evict_inode(struct inode *inode) info =MQUEUE_I (inode);spin_lock (&info->lock);while ((msg =msg_get (info)) !=NULL ) -free_msg (msg); +list_add_tail (&msg->m_list, &tmp_msg);kfree (info->node_cache);spin_unlock (&info->lock); +list_for_each_entry_safe (msg, nmsg, &tmp_msg, m_list) { +list_del (&msg->m_list); +free_msg (msg); + } +/* Total amount of bytes accounted for the mqueue */ mq_treesize = info->attr.mq_maxmsg *sizeof (struct msg_msg ) + min_t(unsigned int, info->attr.mq_maxmsg, MQ_PRIO_MAX) *
ipc/msgutil.c +6 -0
@@ -18,6 +18,7 @@#include <linux/utsname.h> #include <linux/proc_ns.h> #include <linux/uaccess.h> +#include <linux/sched.h> #include "util.h"
@@ -64,6 +65,9 @@ static struct msg_msg *alloc_msg(size_t len) pseg = &msg->next;while (len >0 ) {struct msg_msgseg *seg; + +cond_resched (); + alen =min (len,DATALEN_SEG ); seg =kmalloc (sizeof (*seg) + alen,GFP_KERNEL_ACCOUNT );if (seg ==NULL )
@@ -176,6 +180,8 @@ void free_msg(struct msg_msg *msg)kfree (msg);while (seg !=NULL ) {struct msg_msgseg *tmp = seg->next; + +cond_resched ();kfree (seg); seg = tmp; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 8/155 drm/msm: correct attempted NULL pointer dereference in debugfs
In reply to Greg Kroah-Hartman[ Upstream commit 90f94660e53189755676543954101de78c26253b ]
msm_gem_describe() would attempt to dereference a NULL pointer via the address space pointer when no IOMMU is present. Correct this by adding the appropriate check.
--- drivers/gpu/drm/msm/msm_gem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/msm/msm_gem.c +2 -1
@@ -805,7 +805,8 @@ void msm_gem_describe(struct drm_gem_object *obj, struct seq_file *m)seq_puts (m," vmas:" );list_for_each_entry (vma, &msm_obj->vmas, list) -seq_printf (m," [%s: %08llx,%s,inuse=%d]" , vma->aspace->name, +seq_printf (m," [%s: %08llx,%s,inuse=%d]" , + vma->aspace !=NULL ? vma->aspace->name :NULL , vma->iova, vma->mapped ?"mapped" :"unmapped" , vma->inuse);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 9/155 drm/pl111: Initialize clock spinlock early
In reply to Greg Kroah-Hartman[ Upstream commit 3e01ae2612bdd7975c74ec7123d7f8f5e6eed795 ]
The following warning is seen on systems with broken clock divider.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 1 Comm: swapper Not tainted 5.1.0-09698-g1fb3b52 #1 Hardware name: ARM Integrator/CP (Device Tree) [<c0011be8>] (unwind_backtrace) from [<c000ebb8>] (show_stack+0x10/0x18) [<c000ebb8>] (show_stack) from [<c07d3fd0>] (dump_stack+0x18/0x24) [<c07d3fd0>] (dump_stack) from [<c0060d48>] (register_lock_class+0x674/0x6f8) [<c0060d48>] (register_lock_class) from [<c005de2c>] (__lock_acquire+0x68/0x2128) [<c005de2c>] (__lock_acquire) from [<c0060408>] (lock_acquire+0x110/0x21c) [<c0060408>] (lock_acquire) from [<c07f755c>] (_raw_spin_lock+0x34/0x48) [<c07f755c>] (_raw_spin_lock) from [<c0536c8c>] (pl111_display_enable+0xf8/0x5fc) [<c0536c8c>] (pl111_display_enable) from [<c0502f54>] (drm_atomic_helper_commit_modeset_enables+0x1ec/0x244)
Since commit eedd6033b4c8 ("drm/pl111: Support variants with broken clock divider"), the spinlock is not initialized if the clock divider is broken. Initialize it earlier to fix the problem.
--- drivers/gpu/drm/pl111/pl111_display.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/pl111/pl111_display.c +3 -2
@@ -531,14 +531,15 @@ pl111_init_clock_divider(struct drm_device *drm)dev_err (drm->dev,"CLCD: unable to get clcdclk.\n" );return PTR_ERR (parent); } + +spin_lock_init (&priv->tim2_lock); +/* If the clock divider is broken, use the parent directly */ if (priv->variant->broken_clockdivider) { priv->clk = parent;return 0 ; } parent_name =__clk_get_name (parent); - -spin_lock_init (&priv->tim2_lock); div->init = &init; ret =devm_clk_hw_register (drm->dev, div);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 10/155 mm/mprotect.c: fix compilation warning because of unused mm variable
In reply to Greg Kroah-Hartman[ Upstream commit 94393c78964c432917014e3a456fa15c3e78f741 ]
Since 0cbe3e26abe0 ("mm: update ptep_modify_prot_start/commit to take vm_area_struct as arg") the only place that uses the local 'mm' variable in change_pte_range() is the call to set_pte_at().
Many architectures define set_pte_at() as macro that does not use the 'mm' parameter, which generates the following compilation warning:
CC mm/mprotect.omm/mprotect.c: In function 'change_pte_range':mm/mprotect.c:42:20: warning: unused variable 'mm' [-Wunused-variable]
struct mm_struct *mm = vma->vm_mm;
^~Fix it by passing vma->mm to set_pte_at() and dropping the local 'mm' variable in change_pte_range().
--- mm/mprotect.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
mm/mprotect.c +2 -3
@@ -39,7 +39,6 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd, unsigned long addr, unsigned long end, pgprot_t newprot, int dirty_accountable, int prot_numa) { - struct mm_struct *mm = vma->vm_mm; pte_t *pte, oldpte;spinlock_t *ptl;unsigned long pages =0 ;
@@ -136,7 +135,7 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd, newpte =swp_entry_to_pte (entry);if (pte_swp_soft_dirty (oldpte)) newpte =pte_swp_mksoft_dirty (newpte); -set_pte_at (mm, addr, pte, newpte); +set_pte_at (vma->vm_mm, addr, pte, newpte); pages++; }
@@ -150,7 +149,7 @@ static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd,*/ make_device_private_entry_read (&entry); newpte =swp_entry_to_pte (entry); -set_pte_at (mm, addr, pte, newpte); +set_pte_at (vma->vm_mm, addr, pte, newpte); pages++; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 11/155 ARM: prevent tracing IPI_CPU_BACKTRACE
In reply to Greg Kroah-Hartman[ Upstream commit be167862ae7dd85c56d385209a4890678e1b0488 ]
Patch series "compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING", v3.
This patch (of 11):
When function tracing for IPIs is enabled, we get a warning for an overflow of the ipi_types array with the IPI_CPU_BACKTRACE type as triggered by raise_nmi():
arch/arm/kernel/smp.c: In function 'raise_nmi':
arch/arm/kernel/smp.c:489:2: error: array subscript is above array bounds [-Werror=array-bounds]
trace_ipi_raise(target, ipi_types[ipinr]);
This is a correct warning as we actually overflow the array here.
This patch raise_nmi() to call __smp_cross_call() instead of smp_cross_call(), to avoid calling into ftrace. For clarification, I'm also adding a two new code comments describing how this one is special.
The warning appears to have shown up after commit e7273ff49acf ("ARM:
8488/1: Make IPI_CPU_BACKTRACE a "non-secure" SGI"), which changed the number assignment from '15' to '8', but as far as I can tell has existed since the IPI tracepoints were first introduced. If we decide to backport this patch to stable kernels, we probably need to backport e7273ff49acf as well.
--- arch/arm/include/asm/hardirq.h | 1 + arch/arm/kernel/smp.c | 6 +++++- 2 files changed, 6 insertions(+), 1 deletion(-)
arch/arm/include/asm/hardirq.h +1 -0
@@ -6,6 +6,7 @@#include <linux/threads.h> #include <asm/irq.h> +/* number of IPIS _not_ including IPI_CPU_BACKTRACE */ #define NR_IPI 7 typedef struct {
arch/arm/kernel/smp.c +5 -1
@@ -70,6 +70,10 @@ enum ipi_msg_type {IPI_CPU_STOP ,IPI_IRQ_WORK ,IPI_COMPLETION , +/* +* CPU_BACKTRACE is special and not included in NR_IPI +* or tracable with trace_ipi_* +*/ IPI_CPU_BACKTRACE,/* * SGI8-15 can be reserved by secure firmware, and thus may
@@ -797,7 +801,7 @@ core_initcall(register_cpufreq_notifier);static void raise_nmi (cpumask_t *mask) { -smp_cross_call (mask,IPI_CPU_BACKTRACE ); +__smp_cross_call (mask,IPI_CPU_BACKTRACE ); }void arch_trigger_cpumask_backtrace (const cpumask_t *mask,bool exclude_self)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 12/155 mm/hmm: select mmu notifier when selecting HMM
In reply to Greg Kroah-Hartman[ Upstream commit 734fb89968900b5c5f8edd5038bd4cdeab8c61d2 ]
To avoid random config build issue, select mmu notifier when HMM is selected. In any cases when HMM get selected it will be by users that will also wants the mmu notifier.
--- mm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/Kconfig +1 -1
@@ -694,12 +694,12 @@ config DEV_PAGEMAP_OPS config HMM bool + select MMU_NOTIFIER select MIGRATE_VMA_HELPER config HMM_MIRROR bool "HMM mirror CPU page table into a device page table" depends on ARCH_HAS_HMM - select MMU_NOTIFIER select HMM help Select HMM_MIRROR if you want to mirror range of the CPU page table of a
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 13/155 hugetlbfs: on restore reserve error path retain subpool reservation
In reply to Greg Kroah-Hartman[ Upstream commit 0919e1b69ab459e06df45d3ba6658d281962db80 ]
When a huge page is allocated, PagePrivate() is set if the allocation consumed a reservation. When freeing a huge page, PagePrivate is checked. If set, it indicates the reservation should be restored. PagePrivate being set at free huge page time mostly happens on error paths.
When huge page reservations are created, a check is made to determine if the mapping is associated with an explicitly mounted filesystem. If so, pages are also reserved within the filesystem. The default action when freeing a huge page is to decrement the usage count in any associated explicitly mounted filesystem. However, if the reservation is to be restored the reservation/use count within the filesystem should not be decrementd. Otherwise, a subsequent page allocation and free for the same mapping location will cause the file filesystem usage to go 'negative'.
Filesystem Size Used Avail Use% Mounted on
nodev 4.0G -4.0M 4.1G - /opt/hugepool
To fix, when freeing a huge page do not adjust filesystem usage if PagePrivate() is set to indicate the reservation should be restored.
I did not cc stable as the problem has been around since reserves were added to hugetlbfs and nobody has noticed.
--- mm/hugetlb.c | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-)
mm/hugetlb.c +16 -5
@@ -1258,12 +1258,23 @@ void free_huge_page(struct page *page)ClearPagePrivate (page);/* -* A return code of zero implies that the subpool will be under its -* minimum size if the reservation is not restored after page is free. -* Therefore, force restore_reserve operation. +* If PagePrivate() was set on page, page allocation consumed a +* reservation. If the page was associated with a subpool, there +* would have been a page reserved in the subpool before allocation +* via hugepage_subpool_get_pages(). Since we are 'restoring' the +* reservtion, do not call hugepage_subpool_put_pages() as this will +* remove the reserved page from the subpool. */ -if (hugepage_subpool_put_pages (spool,1 ) ==0 ) - restore_reserve = true; +if (!restore_reserve) { +/* +* A return code of zero implies that the subpool will be +* under its minimum size if the reservation is not restored +* after page is free. Therefore, force restore_reserve +* operation. +*/ +if (hugepage_subpool_put_pages (spool,1 ) ==0 ) + restore_reserve = true; + }spin_lock (&hugetlb_lock);clear_page_huge_active (page);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 14/155 mm/memory_hotplug: release memory resource after arch_remove_memory()
In reply to Greg Kroah-Hartman[ Upstream commit d9eb1417c77df7ce19abd2e41619e9dceccbdf2a ]
Patch series "mm/memory_hotplug: Better error handling when removing memory", v1.
Error handling when removing memory is somewhat messed up right now. Some errors result in warnings, others are completely ignored. Memory unplug code can essentially not deal with errors properly as of now. remove_memory() will never fail.
We have basically two choices:
1. Allow arch_remov_memory() and friends to fail, propagating errors via remove_memory(). Might be problematic (e.g. DIMMs consisting of multiple pieces added/removed separately).
2. Don't allow the functions to fail, handling errors in a nicer way.
It seems like most errors that can theoretically happen are really corner cases and mostly theoretical (e.g. "section not valid"). However e.g. aborting removal of sections while all callers simply continue in case of errors is not nice.
If we can gurantee that removal of memory always works (and WARN/skip in case of theoretical errors so we can figure out what is going on), we can go ahead and implement better error handling when adding memory.
E.g. via add_memory():
arch_add_memory()
ret = do_stuff()
if (ret) {
arch_remove_memory();
goto error;
}Handling here that arch_remove_memory() might fail is basically impossible. So I suggest, let's avoid reporting errors while removing memory, warning on theoretical errors instead and continuing instead of aborting.
This patch (of 4):
__add_pages() doesn't add the memory resource, so __remove_pages() shouldn't remove it. Let's factor it out. Especially as it is a special case for memory used as system memory, added via add_memory() and friends.
We now remove the resource after removing the sections instead of doing it the other way around. I don't think this change is problematic.
add_memory()
register memory resource
arch_add_memory()
remove_memory
arch_remove_memory()
release memory resource
While at it, explain why we ignore errors and that it only happeny if we remove memory in a different granularity as we added it.
--- mm/memory_hotplug.c | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-)
mm/memory_hotplug.c +21 -14
@@ -561,20 +561,6 @@ int __remove_pages(struct zone *zone, unsigned long phys_start_pfn,if (is_dev_zone (zone)) {if (altmap) map_offset =vmem_altmap_offset (altmap); - }else { -resource_size_t start, size; - - start = phys_start_pfn <<PAGE_SHIFT ; - size = nr_pages *PAGE_SIZE ; - - ret =release_mem_region_adjustable (&iomem_resource, start, - size); -if (ret) { -resource_size_t endres = start + size -1 ; - -pr_warn ("Unable to release resource <%pa-%pa> (%d)\n" , - &start, &endres, ret); - } }clear_zone_contiguous (zone);
@@ -1843,6 +1829,26 @@ void try_offline_node(int nid) }EXPORT_SYMBOL (try_offline_node); +static void __release_memory_resource (resource_size_t start, +resource_size_t size) +{ +int ret; + +/* +* When removing memory in the same granularity as it was added, +* this function never fails. It might only fail if resources +* have to be adjusted or split. We'll ignore the error, as +* removing of memory cannot fail. +*/ + ret =release_mem_region_adjustable (&iomem_resource, start, size); +if (ret) { +resource_size_t endres = start + size -1 ; + +pr_warn ("Unable to release resource <%pa-%pa> (%d)\n" , + &start, &endres, ret); + } +} +/** * remove_memory * @nid: the node ID
@@ -1877,6 +1883,7 @@ void __ref __remove_memory(int nid, u64 start, u64 size)memblock_remove (start, size);arch_remove_memory (nid, start, size,NULL ); +__release_memory_resource (start, size);try_offline_node (nid);
Signature · 1 line
2.20.1
stable-rc/linux-5.1.y boot: 59 boots: 0 failed, 59 passed (v5.1.9-156-g10f90b20eaf9)
stable-rc/linux-5.1.y boot: 59 boots: 0 failed, 59 passed (v5.1.9-156-g10f90b20eaf9)
Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.1.y/kernel/v5.1.9-156-g10f90b20eaf9/
Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.1.y/kernel/v5.1.9-156-g10f90b20eaf9/
Tree: stable-rc
Branch: linux-5.1.y
Git Describe: v5.1.9-156-g10f90b20eaf9
Git Commit: 10f90b20eaf9cf31c4ea0cbaf10dfdd807834a6c
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Tested: 29 unique boards, 14 SoC families, 11 builds out of 209
---
For more info write to <[email protected]>
Greg Kroah-Hartman
maintainerPATCH 15/155 mem-hotplug: fix node spanned pages when we have a node with only ZONE_MOVABLE
In reply to Greg Kroah-Hartman[ Upstream commit 299c83dce9ea3a79bb4b5511d2cb996b6b8e5111 ]
342332e6a925 ("mm/page_alloc.c: introduce kernelcore=mirror option") and later patches rewrote the calculation of node spanned pages.
e506b99696a2 ("mem-hotplug: fix node spanned pages when we have a movable node"), but the current code still has problems,
When we have a node with only zone_movable and the node id is not zero, the size of node spanned pages is double added.
That's because we have an empty normal zone, and zone_start_pfn or zone_end_pfn is not between arch_zone_lowest_possible_pfn and arch_zone_highest_possible_pfn, so we need to use clamp to constrain the range just like the commit <96e907d13602> (bootmem: Reimplement __absent_pages_in_range() using for_each_mem_pfn_range()).
e.g.
Zone ranges:
DMA [mem 0x0000000000001000-0x0000000000ffffff] DMA32 [mem 0x0000000001000000-0x00000000ffffffff] Normal [mem 0x0000000100000000-0x000000023fffffff]
Movable zone start for each node
Node 0: 0x0000000100000000
Node 1: 0x0000000140000000
Early memory node ranges
node 0: [mem 0x0000000000001000-0x000000000009efff] node 0: [mem 0x0000000000100000-0x00000000bffdffff] node 0: [mem 0x0000000100000000-0x000000013fffffff] node 1: [mem 0x0000000140000000-0x000000023fffffff]
node 0 DMA spanned:0xfff present:0xf9e absent:0x61
node 0 DMA32 spanned:0xff000 present:0xbefe0 absent:0x40020
node 0 Normal spanned:0 present:0 absent:0
node 0 Movable spanned:0x40000 present:0x40000 absent:0
On node 0 totalpages(node_present_pages): 1048446 node_spanned_pages:1310719
node 1 DMA spanned:0 present:0 absent:0
node 1 DMA32 spanned:0 present:0 absent:0
node 1 Normal spanned:0x100000 present:0x100000 absent:0
node 1 Movable spanned:0x100000 present:0x100000 absent:0
On node 1 totalpages(node_present_pages): 2097152 node_spanned_pages:2097152
Memory: 6967796K/12582392K available (16388K kernel code, 3686K rwdata, 4468K rodata, 2160K init, 10444K bss, 5614596K reserved, 0K cma-reserved)
It shows that the current memory of node 1 is double added. After this patch, the problem is fixed.
node 0 DMA spanned:0xfff present:0xf9e absent:0x61
node 0 DMA32 spanned:0xff000 present:0xbefe0 absent:0x40020
node 0 Normal spanned:0 present:0 absent:0
node 0 Movable spanned:0x40000 present:0x40000 absent:0
On node 0 totalpages(node_present_pages): 1048446 node_spanned_pages:1310719
node 1 DMA spanned:0 present:0 absent:0
node 1 DMA32 spanned:0 present:0 absent:0
node 1 Normal spanned:0 present:0 absent:0
node 1 Movable spanned:0x100000 present:0x100000 absent:0
On node 1 totalpages(node_present_pages): 1048576 node_spanned_pages:1048576
memory: 6967796K/8388088K available (16388K kernel code, 3686K rwdata, 4468K rodata, 2160K init, 10444K bss, 1420292K reserved, 0K cma-reserved)
--- mm/page_alloc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
mm/page_alloc.c +4 -2
@@ -6244,13 +6244,15 @@ static unsigned long __init zone_spanned_pages_in_node(int nid,unsigned long *zone_end_pfn, unsigned long *ignored) { + unsigned long zone_low = arch_zone_lowest_possible_pfn[zone_type]; +unsigned long zone_high = arch_zone_highest_possible_pfn[zone_type];/* When hotadd a new node from cpu_up(), the node should be empty */ if (!node_start_pfn && !node_end_pfn)return 0 ;/* Get the start and end of the zone */ - *zone_start_pfn = arch_zone_lowest_possible_pfn[zone_type]; - *zone_end_pfn = arch_zone_highest_possible_pfn[zone_type]; + *zone_start_pfn =clamp (node_start_pfn, zone_low, zone_high); + *zone_end_pfn =clamp (node_end_pfn, zone_low, zone_high);adjust_zone_range_for_zone_movable (nid, zone_type, node_start_pfn, node_end_pfn, zone_start_pfn, zone_end_pfn);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 16/155 mm/cma.c: fix crash on CMA allocation if bitmap allocation fails
In reply to Greg Kroah-Hartman[ Upstream commit 1df3a339074e31db95c4790ea9236874b13ccd87 ]
f022d8cb7ec7 ("mm: cma: Don't crash on allocation if CMA area can't be activated") fixes the crash issue when activation fails via setting cma->count as 0, same logic exists if bitmap allocation fails.
--- mm/cma.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
mm/cma.c +3 -1
@@ -106,8 +106,10 @@ static int __init cma_activate_area(struct cma *cma) cma->bitmap =kzalloc (bitmap_size,GFP_KERNEL ); -if (!cma->bitmap) +if (!cma->bitmap) { + cma->count =0 ;return -ENOMEM ; + }WARN_ON_ONCE (!pfn_valid (pfn)); zone =page_zone (pfn_to_page (pfn));
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 17/155 initramfs: free initrd memory if opening /initrd.image fails
In reply to Greg Kroah-Hartman[ Upstream commit 54c7a8916a887f357088f99e9c3a7720cd57d2c8 ]
Patch series "initramfs tidyups".
I've spent some time chasing down behavior in initramfs and found plenty of opportunity to improve the code. A first stab on that is contained in this series.
This patch (of 7):
We free the initrd memory for all successful or error cases except for the case where opening /initrd.image fails, which looks like an oversight.
Steven said:
: This also changes the behaviour when CONFIG_INITRAMFS_FORCE is enabled : - specifically it means that the initrd is freed (previously it was : ignored and never freed). But that seems like reasonable behaviour and : the previous behaviour looks like another oversight.
--- init/initramfs.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-)
init/initramfs.c +6 -8
@@ -612,13 +612,12 @@ static int __init populate_rootfs(void)printk (KERN_INFO "Trying to unpack rootfs image as initramfs...\n" ); err =unpack_to_rootfs ((char *)initrd_start, initrd_end - initrd_start); -if (!err) { -free_initrd (); +if (!err) goto done; - }else { -clean_rootfs (); -unpack_to_rootfs (__initramfs_start, __initramfs_size); - } + +clean_rootfs (); +unpack_to_rootfs (__initramfs_start, __initramfs_size); +printk (KERN_INFO "rootfs image is not initramfs (%s)" "; looks like an initrd\n" , err); fd = ksys_open("/initrd.image",
@@ -632,7 +631,6 @@ static int __init populate_rootfs(void) written, initrd_end - initrd_start);ksys_close (fd); -free_initrd (); } done:/* empty statement */ ;
@@ -642,9 +640,9 @@ static int __init populate_rootfs(void) initrd_end - initrd_start);if (err)printk (KERN_EMERG "Initramfs unpacking failed: %s\n" , err); -free_initrd ();#endif } +free_initrd ();flush_delayed_fput ();return 0 ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 18/155 mm/compaction.c: fix an undefined behaviour
In reply to Greg Kroah-Hartman[ Upstream commit dd7ef7bd14640f11763b54f55131000165f48321 ]
In a low-memory situation, cc->fast_search_fail can keep increasing as it is unable to find an available page to isolate in fast_isolate_freepages(). As the result, it could trigger an error below, so just compare with the maximum bits can be shifted first.
UBSAN: Undefined behaviour in mm/compaction.c:1160:30 shift exponent 64 is too large for 64-bit type 'unsigned long' CPU: 131 PID: 1308 Comm: kcompactd1 Kdump: loaded Tainted: G W L 5.0.0+ #17 Call trace: dump_backtrace+0x0/0x450 show_stack+0x20/0x2c dump_stack+0xc8/0x14c __ubsan_handle_shift_out_of_bounds+0x7e8/0x8c4 compaction_alloc+0x2344/0x2484 unmap_and_move+0xdc/0x1dbc migrate_pages+0x274/0x1310 compact_zone+0x26ec/0x43bc kcompactd+0x15b8/0x1a24 kthread+0x374/0x390 ret_from_fork+0x10/0x18
--- mm/compaction.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
mm/compaction.c +3 -1
@@ -1164,7 +1164,9 @@ static bool suitable_migration_target(struct compact_control *cc,static inline unsigned int freelist_scan_limit (struct compact_control *cc) { -return (COMPACT_CLUSTER_MAX >> cc->fast_search_fail) +1 ; +unsigned short shift =BITS_PER_LONG -1 ; + +return (COMPACT_CLUSTER_MAX >>min (shift, cc->fast_search_fail)) +1 ; }/*
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 19/155 mm/memory_hotplug.c: fix the wrong usage of N_HIGH_MEMORY
In reply to Greg Kroah-Hartman[ Upstream commit d3ba3ae19751e476b0840a0c9a673a5766fa3219 ]
In node_states_check_changes_online(), N_HIGH_MEMORY is used to substitute ZONE_HIGHMEM directly. This is not right. N_HIGH_MEMORY is to mark the memory state of node. Here zone index is checked, which should be compared with 'ZONE_HIGHMEM' accordingly.
Replace it with ZONE_HIGHMEM.
This is a code cleanup - no known runtime effects.
--- mm/memory_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/memory_hotplug.c +1 -1
@@ -700,7 +700,7 @@ static void node_states_check_changes_online(unsigned long nr_pages,if (zone_idx (zone) <=ZONE_NORMAL && !node_state (nid,N_NORMAL_MEMORY )) arg->status_change_nid_normal = nid;#ifdef CONFIG_HIGHMEM -if (zone_idx (zone) <=N_HIGH_MEMORY && !node_state (nid,N_HIGH_MEMORY )) +if (zone_idx (zone) <=ZONE_HIGHMEM && !node_state (nid,N_HIGH_MEMORY )) arg->status_change_nid_high = nid;#endif }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 20/155 mm/cma.c: fix the bitmap status to show failed allocation reason
In reply to Greg Kroah-Hartman[ Upstream commit 2b59e01a3aa665f751d1410b99fae9336bd424e1 ]
Currently one bit in cma bitmap represents number of pages rather than one page, cma->count means cma size in pages. So to find available pages via find_next_zero_bit()/find_next_bit() we should use cma size not in pages but in bits although current free pages number is correct due to zero value of order_per_bit. Once order_per_bit is changed the bitmap status will be incorrect.
The size input in cma_debug_show_areas() is not correct. It will affect the available pages at some position to debug the failure issue.
This is an example with order_per_bit = 1
Before this change:
[ 4.120060] cma: number of available pages: 1@93+4@108+7@121+7@137+7@153+7@169+7@185+7@201+3@213+3@221+3@229+3@237+3@245+3@253+3@261+3@269+3@277+3@285+3@293+3@301+3@309+3@317+3@325+19@333+15@369+512@512=> 638 free of 1024 total pages
After this change:
[ 4.143234] cma: number of available pages: 2@93+8@108+14@121+14@137+14@153+14@169+14@185+14@201+6@213+6@221+6@229+6@237+6@245+6@253+6@261+6@269+6@277+6@285+6@293+6@301+6@309+6@317+6@325+38@333+30@369=> 252 free of 1024 total pages
Obviously the bitmap status before is incorrect.
--- mm/cma.c | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-)
mm/cma.c +11 -8
@@ -369,23 +369,26 @@ err:#ifdef CONFIG_CMA_DEBUG static void cma_debug_show_areas (struct cma *cma) { -unsigned long next_zero_bit, next_set_bit; +unsigned long next_zero_bit, next_set_bit, nr_zero;unsigned long start =0 ; -unsigned int nr_zero, nr_total =0 ; +unsigned long nr_part, nr_total =0 ; +unsigned long nbits =cma_bitmap_maxno (cma);mutex_lock (&cma->lock);pr_info ("number of available pages: " );for (;;) { - next_zero_bit =find_next_zero_bit (cma->bitmap, cma->count, start); -if (next_zero_bit >= cma->count) + next_zero_bit =find_next_zero_bit (cma->bitmap, nbits, start); +if (next_zero_bit >= nbits)break ; - next_set_bit =find_next_bit (cma->bitmap, cma->count, next_zero_bit); + next_set_bit =find_next_bit (cma->bitmap, nbits, next_zero_bit); nr_zero = next_set_bit - next_zero_bit; -pr_cont ("%s%u@%lu" , nr_total ?"+" :"" , nr_zero, next_zero_bit); - nr_total += nr_zero; + nr_part = nr_zero << cma->order_per_bit; +pr_cont ("%s%lu@%lu" , nr_total ?"+" :"" , nr_part, + next_zero_bit); + nr_total += nr_part; start = next_zero_bit + nr_zero; } -pr_cont ("=> %u free of %lu total pages\n" , nr_total, cma->count); +pr_cont ("=> %lu free of %lu total pages\n" , nr_total, cma->count);mutex_unlock (&cma->lock); }#else
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 21/155 mm: page_mkclean vs MADV_DONTNEED race
In reply to Greg Kroah-Hartman[ Upstream commit 024eee0e83f0df52317be607ca521e0fc572aa07 ]
MADV_DONTNEED is handled with mmap_sem taken in read mode. We call page_mkclean without holding mmap_sem.
MADV_DONTNEED implies that pages in the region are unmapped and subsequent access to the pages in that range is handled as a new page fault. This implies that if we don't have parallel access to the region when MADV_DONTNEED is run we expect those range to be unallocated.
w.r.t page_mkclean() we need to make sure that we don't break the MADV_DONTNEED semantics. MADV_DONTNEED check for pmd_none without holding pmd_lock. This implies we skip the pmd if we temporarily mark pmd none. Avoid doing that while marking the page clean.
Keep the sequence same for dax too even though we don't support MADV_DONTNEED for dax mapping
The bug was noticed by code review and I didn't observe any failures w.r.t test run. This is similar to
commit 58ceeb6bec86d9140f9d91d71a710e963523d063
Author: Kirill A. Shutemov <[email protected]> Date: Thu Apr 13 14:56:26 2017 -0700
thp: fix MADV_DONTNEED vs. MADV_FREE race
commit ced108037c2aa542b3ed8b7afd1576064ad1362a
Author: Kirill A. Shutemov <[email protected]> Date: Thu Apr 13 14:56:20 2017 -0700
thp: fix MADV_DONTNEED vs. numa balancing race
--- fs/dax.c | 2 +- mm/rmap.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
fs/dax.c +1 -1
@@ -814,7 +814,7 @@ static void dax_entry_mkclean(struct address_space *mapping, pgoff_t index, goto unlock_pmd;flush_cache_page (vma, address, pfn); - pmd =pmdp_huge_clear_flush (vma, address, pmdp); + pmd =pmdp_invalidate (vma, address, pmdp); pmd =pmd_wrprotect (pmd); pmd =pmd_mkclean (pmd);set_pmd_at (vma->vm_mm, address, pmdp, pmd);
mm/rmap.c +1 -1
@@ -928,7 +928,7 @@ static bool page_mkclean_one(struct page *page, struct vm_area_struct *vma,continue ;flush_cache_page (vma, address,page_to_pfn (page)); - entry =pmdp_huge_clear_flush (vma, address, pmd); + entry =pmdp_invalidate (vma, address, pmd); entry =pmd_wrprotect (entry); entry =pmd_mkclean (entry);set_pmd_at (vma->vm_mm, address, pmd, entry);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 22/155 mm/cma_debug.c: fix the break condition in cma_maxchunk_get()
In reply to Greg Kroah-Hartman[ Upstream commit f0fd50504a54f5548eb666dc16ddf8394e44e4b7 ]
If not find zero bit in find_next_zero_bit(), it will return the size parameter passed in, so the start bit should be compared with bitmap_maxno rather than cma->count. Although getting maxchunk is working fine due to zero value of order_per_bit currently, the operation will be stuck if order_per_bit is set as non-zero.
--- mm/cma_debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
mm/cma_debug.c +1 -1
@@ -56,7 +56,7 @@ static int cma_maxchunk_get(void *data, u64 *val)mutex_lock (&cma->lock);for (;;) { start =find_next_zero_bit (cma->bitmap, bitmap_maxno, end); -if (start >= cma->count) +if (start >= bitmap_maxno)break ; end =find_next_bit (cma->bitmap, bitmap_maxno, start); maxchunk =max (end - start, maxchunk);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 23/155 mm/slab.c: fix an infinite loop in leaks_show()
In reply to Greg Kroah-Hartman[ Upstream commit 745e10146c31b1c6ed3326286704ae251b17f663 ]
"cat /proc/slab_allocators" could hang forever on SMP machines with kmemleak or object debugging enabled due to other CPUs running do_drain() will keep making kmemleak_object or debug_objects_cache dirty and unable to escape the first loop in leaks_show(),
do {
set_store_user_clean(cachep);
drain_cpu_caches(cachep);
...} while (!is_store_user_clean(cachep));
For example,
do_drain
slabs_destroy
slab_destroy
kmem_cache_free
__cache_free
___cache_free
kmemleak_free_recursive
delete_object_full
__delete_object
put_object
free_object_rcu
kmem_cache_free
cache_free_debugcheck --> dirty kmemleak_objectOne approach is to check cachep->name and skip both kmemleak_object and debug_objects_cache in leaks_show(). The other is to set store_user_clean after drain_cpu_caches() which leaves a small window between drain_cpu_caches() and set_store_user_clean() where per-CPU caches could be dirty again lead to slightly wrong information has been stored but could also speed up things significantly which sounds like a good compromise. For example,
# cat /proc/slab_allocators 0m42.778s # 1st approach 0m0.737s # 2nd approach
--- mm/slab.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
mm/slab.c +5 -1
@@ -4328,8 +4328,12 @@ static int leaks_show(struct seq_file *m, void *p)* whole processing. */ do { - set_store_user_clean(cachep); drain_cpu_caches(cachep); + /* + * drain_cpu_caches() could make kmemleak_object and + * debug_objects_cache dirty, so reset afterwards. + */ + set_store_user_clean(cachep); x[1] = 0;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 24/155 kernel/sys.c: prctl: fix false positive in validate_prctl_map()
In reply to Greg Kroah-Hartman[ Upstream commit a9e73998f9d705c94a8dca9687633adc0f24a19a ]
While validating new map we require the @start_data to be strictly less than @end_data, which is fine for regular applications (this is why this nit didn't trigger for that long). These members are set from executable loaders such as elf handers, still it is pretty valid to have a loadable data section with zero size in file, in such case the start_data is equal to end_data once kernel loader finishes.
As a result when we're trying to restore such programs the procedure fails and the kernel returns -EINVAL. From the image dump of a program:
| "mm_start_code": "0x400000", | "mm_end_code": "0x8f5fb4", | "mm_start_data": "0xf1bfb0", | "mm_end_data": "0xf1bfb0",
Thus we need to change validate_prctl_map from strictly less to less or equal operator use.
--- kernel/sys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/sys.c +1 -1
@@ -1924,7 +1924,7 @@ static int validate_prctl_map(struct prctl_mm_map *prctl_map) ((unsigned long)prctl_map->__m1 __op \ (unsigned long)prctl_map->__m2) ? 0 : -EINVAL error = __prctl_check_order(start_code, <, end_code); - error |= __prctl_check_order(start_data, <, end_data); + error |= __prctl_check_order(start_data,<=, end_data); error |= __prctl_check_order(start_brk, <=, brk); error |= __prctl_check_order(arg_start, <=, arg_end); error |= __prctl_check_order(env_start, <=, env_end);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 25/155 thermal: rcar_gen3_thermal: disable interrupt in .remove
In reply to Greg Kroah-Hartman[ Upstream commit 63f55fcea50c25ae5ad45af92d08dae3b84534c2 ]
Currently IRQ remains enabled after .remove, later if device is probed, IRQ is requested before .thermal_init, this may cause IRQ function be called before device is initialized.
this patch disables interrupt in .remove, to ensure irq function only be called after device is fully initialized.
--- drivers/thermal/rcar_gen3_thermal.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/thermal/rcar_gen3_thermal.c +3 -0
@@ -331,6 +331,9 @@ MODULE_DEVICE_TABLE(of, rcar_gen3_thermal_dt_ids);static int rcar_gen3_thermal_remove (struct platform_device *pdev) {struct device *dev = &pdev->dev; +struct rcar_gen3_thermal_priv *priv =dev_get_drvdata (dev); + +rcar_thermal_irq_set (priv, false);pm_runtime_put (dev);pm_runtime_disable (dev);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 26/155 drivers: thermal: tsens: Dont print error message on -EPROBE_DEFER
In reply to Greg Kroah-Hartman[ Upstream commit fc7d18cf6a923cde7f5e7ba2c1105bb106d3e29a ]
We print a calibration failure message on -EPROBE_DEFER from nvmem/qfprom as follows:
[ 3.003090] qcom-tsens 4a9000.thermal-sensor: version: 1.4 [ 3.005376] qcom-tsens 4a9000.thermal-sensor: tsens calibration failed [ 3.113248] qcom-tsens 4a9000.thermal-sensor: version: 1.4
This confuses people when, in fact, calibration succeeds later when nvmem/qfprom device is available. Don't print this message on a -EPROBE_DEFER.
--- drivers/thermal/qcom/tsens.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/thermal/qcom/tsens.c +2 -1
@@ -160,7 +160,8 @@ static int tsens_probe(struct platform_device *pdev)if (tmdev->ops->calibrate) { ret = tmdev->ops->calibrate (tmdev);if (ret <0 ) { -dev_err (dev,"tsens calibration failed\n" ); +if (ret != -EPROBE_DEFER ) +dev_err (dev,"tsens calibration failed\n" );return ret; } }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 27/155 mfd: tps65912-spi: Add missing of table registration
In reply to Greg Kroah-Hartman[ Upstream commit 9e364e87ad7f2c636276c773d718cda29d62b741 ]
MODULE_DEVICE_TABLE(of, <of_match_table> should be called to complete DT OF mathing mechanism and register it.
Before this patch:
modinfo drivers/mfd/tps65912-spi.ko | grep alias
alias: spi:tps65912
After this patch:
modinfo drivers/mfd/tps65912-spi.ko | grep alias
alias: of:N*T*Cti,tps65912C* alias: of:N*T*Cti,tps65912 alias: spi:tps65912
--- drivers/mfd/tps65912-spi.c | 1 + 1 file changed, 1 insertion(+)
drivers/mfd/tps65912-spi.c +1 -0
@@ -27,6 +27,7 @@ static const struct of_device_id tps65912_spi_of_match_table[] = { { .compatible = "ti,tps65912", }, {/* sentinel */ } }; +MODULE_DEVICE_TABLE (of, tps65912_spi_of_match_table);static int tps65912_spi_probe (struct spi_device *spi) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 28/155 mfd: intel-lpss: Set the device in reset state when init
In reply to Greg Kroah-Hartman[ Upstream commit dad06532292d77f37fbe831a02948a593500f682 ]
In virtualized setup, when system reboots due to warm reset interrupt storm is seen.
Call Trace: <IRQ> dump_stack+0x70/0xa5 __report_bad_irq+0x2e/0xc0 note_interrupt+0x248/0x290 ? add_interrupt_randomness+0x30/0x220 handle_irq_event_percpu+0x54/0x80 handle_irq_event+0x39/0x60 handle_fasteoi_irq+0x91/0x150 handle_irq+0x108/0x180 do_IRQ+0x52/0xf0 common_interrupt+0xf/0xf </IRQ> RIP: 0033:0x76fc2cfabc1d Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e
94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18 <48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04 24
RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda
RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce
RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010
RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0
R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0
R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414 handlers:
[<000000000d3fa913>] idma64_irq
Disabling IRQ #27
To avoid interrupt storm, set the device in reset state before bringing out the device from reset state.
Changelog v2:
- correct the subject line by adding "mfd: "
--- drivers/mfd/intel-lpss.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/mfd/intel-lpss.c +3 -0
@@ -273,6 +273,9 @@ static void intel_lpss_init_dev(const struct intel_lpss *lpss) {u32 value =LPSS_PRIV_SSP_REG_DIS_DMA_FIN ; +/* Set the device in reset state */ +writel (0 , lpss->priv +LPSS_PRIV_RESETS ); +intel_lpss_deassert_reset (lpss);intel_lpss_set_remap_addr (lpss);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 29/155 drm/nouveau/disp/dp: respect sink limits when selecting failsafe link configuration
In reply to Greg Kroah-Hartman[ Upstream commit 13d03e9daf70dab032c03dc172e75bb98ad899c4 ]
Where possible, we want the failsafe link configuration (one which won't hang the OR during modeset because of not enough bandwidth for the mode) to also be supported by the sink.
This prevents "link rate unsupported by sink" messages when link training fails.
--- drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nvkm/engine/disp/dp.c +9 -2
@@ -365,8 +365,15 @@ nvkm_dp_train(struct nvkm_dp *dp, u32 dataKBps)* and it's better to have a failed modeset than that. */ for (cfg = nvkm_dp_rates; cfg->rate; cfg++) { -if (cfg->nr <= outp_nr && cfg->nr <= outp_bw) - failsafe = cfg; +if (cfg->nr <= outp_nr && cfg->nr <= outp_bw) { +/* Try to respect sink limits too when selecting +* lowest link configuration. +*/ +if (!failsafe || + (cfg->nr <= sink_nr && cfg->bw <= sink_bw)) + failsafe = cfg; + } +if (failsafe && cfg[1 ].rate < dataKBps)break ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 30/155 mfd: twl6040: Fix device init errors for ACCCTL register
In reply to Greg Kroah-Hartman[ Upstream commit 48171d0ea7caccf21c9ee3ae75eb370f2a756062 ]
I noticed that we can get a -EREMOTEIO errors on at least omap4 duovero:
twl6040 0-004b: Failed to write 2d = 19: -121
And then any following register access will produce errors.
There 2d offset above is register ACCCTL that gets written on twl6040 powerup. With error checking added to the related regcache_sync() call, the -EREMOTEIO error is reproducable on twl6040 powerup at least duovero.
To fix the error, we need to wait until twl6040 is accessible after the powerup. Based on tests on omap4 duovero, we need to wait over 8ms after powerup before register write will complete without failures. Let's also make sure we warn about possible errors too.
Note that we have twl6040_patch[] reg_sequence with the ACCCTL register configuration and regcache_sync() will write the new value to ACCCTL.
--- drivers/mfd/twl6040.c | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
drivers/mfd/twl6040.c +12 -1
@@ -322,8 +322,19 @@ int twl6040_power(struct twl6040 *twl6040, int on) } } +/* +* Register access can produce errors after power-up unless we +* wait at least 8ms based on measurements on duovero. +*/ +usleep_range (10000 ,12000 ); +/* Sync with the HW */ -regcache_sync (twl6040->regmap); + ret =regcache_sync (twl6040->regmap); +if (ret) { +dev_err (twl6040->dev,"Failed to sync with the HW: %i\n" , + ret); + goto out; + }/* Default PLL configuration after power up */ twl6040->pll =TWL6040_SYSCLK_SEL_LPPLL ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 31/155 perf/x86/intel: Allow PEBS multi-entry in watermark mode
In reply to Greg Kroah-Hartman[ Upstream commit c7a286577d7592720c2f179aadfb325a1ff48c95 ]
This patch fixes a restriction/bug introduced by:
583feb08e7f7 ("perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS")
The original patch prevented using multi-entry PEBS when wakeup_events != 0. However given that wakeup_events is part of a union with wakeup_watermark, it means that in watermark mode, PEBS multi-entry is also disabled which is not the intent. This patch fixes this by checking is watermark mode is enabled.
--- arch/x86/events/intel/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/events/intel/core.c +1 -1
@@ -3189,7 +3189,7 @@ static int intel_pmu_hw_config(struct perf_event *event)return ret;if (event->attr.precise_ip) { -if (!(event->attr.freq || event->attr.wakeup_events)) { +if (!(event->attr.freq || (event->attr.wakeup_events && !event->attr.watermark))) { event->hw.flags |=PERF_X86_EVENT_AUTO_RELOAD ;if (!(event->attr.sample_type & ~intel_pmu_large_pebs_flags (event)))
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 32/155 drm/nouveau/kms/gf119-gp10x: push HeadSetControlOutputResource() mthd when encoders change
In reply to Greg Kroah-Hartman[ Upstream commit a0b694d0af21c9993d1a39a75fd814bd48bf7eb4 ]
HW has error checks in place which check that pixel depth is explicitly provided on DP, while HDMI has a "default" setting that we use.
In multi-display configurations with identical modelines, but different protocols (HDMI + DP, in this case), it was possible for the DP head to get swapped to the head which previously drove the HDMI output, without updating HeadSetControlOutputResource(), triggering the error check and hanging the core update.
--- drivers/gpu/drm/nouveau/dispnv50/head.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/nouveau/dispnv50/head.c +1 -1
@@ -306,7 +306,7 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct drm_crtc_state *state) asyh->set.or = head->func->or !=NULL ; } -if (asyh->state.mode_changed) +if (asyh->state.mode_changed || asyh->state.connectors_changed)nv50_head_atomic_check_mode (head, asyh); if (asyh->state.color_mgmt_changed ||
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 33/155 drm/nouveau: fix duplication of nv50_head_atom struct
In reply to Greg Kroah-Hartman[ Upstream commit c4a52d669690423ee3c99d8eda1e69cd0821fcad ]
nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom struct. This patch adds copying of struct member named "or", which previously was left uninitialized in the duplicated structure.
Due to this bug, incorrect nhsync and nvsync values were sometimes used. In my particular case, that lead to a mismatch between the output resolution of the graphics device (GeForce GT 630 OEM) and the reported input signal resolution on the display. xrandr reported 1680x1050, but the display reported 1280x1024. As a result of this mismatch, the output on the display looked like it was cropped (only part of the output was actually visible on the display).
git bisect pointed to commit 2ca7fb5c1cc6 ("drm/nouveau/kms/nv50: handle SetControlOutputResource from head"), which added the member "or" to nv50_head_atom structure, but forgot to copy it in nv50_head_atomic_duplicate_state().
--- drivers/gpu/drm/nouveau/dispnv50/head.c | 1 + 1 file changed, 1 insertion(+)
drivers/gpu/drm/nouveau/dispnv50/head.c +1 -0
@@ -413,6 +413,7 @@ nv50_head_atomic_duplicate_state(struct drm_crtc *crtc) asyh->ovly = armh->ovly; asyh->dither = armh->dither; asyh->procamp = armh->procamp; + asyh->or = armh->or; asyh->dp = armh->dp; asyh->clr.mask =0 ; asyh->set.mask =0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 34/155 drm/bridge: adv7511: Fix low refresh rate selection
In reply to Greg Kroah-Hartman[ Upstream commit 67793bd3b3948dc8c8384b6430e036a30a0ecb43 ]
The driver currently sets register 0xfb (Low Refresh Rate) based on the value of mode->vrefresh. Firstly, this field is specified to be in Hz, but the magic numbers used by the code are Hz * 1000. This essentially leads to the low refresh rate always being set to 0x01, since the vrefresh value will always be less than 24000. Fix the magic numbers to be in Hz.
Secondly, according to the comment in drm_modes.h, the field is not supposed to be used in a functional way anyway. Instead, use the helper function drm_mode_vrefresh().
--- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +3 -3
@@ -748,11 +748,11 @@ static void adv7511_mode_set(struct adv7511 *adv7511, vsync_polarity =1 ; } -if (mode->vrefresh <=24000 ) +if (drm_mode_vrefresh (mode) <=24 ) low_refresh_rate =ADV7511_LOW_REFRESH_RATE_24HZ ; -else if (mode->vrefresh <=25000 ) +else if (drm_mode_vrefresh (mode) <=25 ) low_refresh_rate =ADV7511_LOW_REFRESH_RATE_25HZ ; -else if (mode->vrefresh <=30000 ) +else if (drm_mode_vrefresh (mode) <=30 ) low_refresh_rate =ADV7511_LOW_REFRESH_RATE_30HZ ;else low_refresh_rate =ADV7511_LOW_REFRESH_RATE_NONE ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 35/155 objtool: Dont use ignore flag for fake jumps
In reply to Greg Kroah-Hartman[ Upstream commit e6da9567959e164f82bc81967e0d5b10dee870b4 ]
The ignore flag is set on fake jumps in order to keep add_jump_destinations() from setting their jump_dest, since it already got set when the fake jump was created.
But using the ignore flag is a bit of a hack. It's normally used to skip validation of an instruction, which doesn't really make sense for fake jumps.
Also, after the next patch, using the ignore flag for fake jumps can trigger a false "why am I validating an ignored function?" warning.
Instead just add an explicit check in add_jump_destinations() to skip fake jumps.
--- tools/objtool/check.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
tools/objtool/check.c +5 -3
@@ -28,6 +28,8 @@#include <linux/hashtable.h> #include <linux/kernel.h> +#define FAKE_JUMP_OFFSET -1 +struct alternative {struct list_head list;struct instruction *insn;
@@ -501,7 +503,7 @@ static int add_jump_destinations(struct objtool_file *file) insn->type != INSN_JUMP_UNCONDITIONAL)continue ; -if (insn->ignore) +if (insn->ignore || insn->offset ==FAKE_JUMP_OFFSET )continue ; rela = find_rela_by_dest_range(insn->sec, insn->offset,
@@ -670,10 +672,10 @@ static int handle_group_alt(struct objtool_file *file,clear_insn_state (&fake_jump->state); fake_jump->sec = special_alt->new_sec; - fake_jump->offset =-1 ; + fake_jump->offset =FAKE_JUMP_OFFSET ; fake_jump->type =INSN_JUMP_UNCONDITIONAL ; fake_jump->jump_dest =list_next_entry (last_orig_insn, list); - fake_jump->ignore = true; + fake_jump->func = orig_insn->func; }if (!special_alt->new_len) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 36/155 drm/nouveau/kms/gv100-: fix spurious window immediate interlocks
In reply to Greg Kroah-Hartman[ Upstream commit d2434e4d942c32cadcbdbcd32c58f35098f3b604 ]
Cursor position updates were accidentally causing us to attempt to interlock window with window immediate, and without a matching window immediate update, NVDisplay could hang forever in some circumstances.
Fixes suspend/resume on (at least) Quadro RTX4000 (TU104).
--- drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 + drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c | 1 + drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 +- 3 files changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/nouveau/dispnv50/disp.h +1 -0
@@ -41,6 +41,7 @@ struct nv50_disp_interlock { NV50_DISP_INTERLOCK__SIZE } type;u32 data; +u32 wimm; };void corec37d_ntfy_init (struct nouveau_bo *,u32 );
drivers/gpu/drm/nouveau/dispnv50/wimmc37b.c +1 -0
@@ -75,6 +75,7 @@ wimmc37b_init_(const struct nv50_wimm_func *func, struct nouveau_drm *drm,return ret; } + wndw->interlock.wimm = wndw->interlock.data; wndw->immd = func;return 0 ; }
drivers/gpu/drm/nouveau/dispnv50/wndw.c +1 -1
@@ -149,7 +149,7 @@ nv50_wndw_flush_set(struct nv50_wndw *wndw, u32 *interlock,if (asyw->set.point) {if (asyw->set.point = false, asyw->set.mask) interlock[wndw->interlock.type] |= wndw->interlock.data; - interlock[NV50_DISP_INTERLOCK_WIMM ] |= wndw->interlock.data; + interlock[NV50_DISP_INTERLOCK_WIMM ] |= wndw->interlock.wimm; wndw->immd->point (wndw, asyw); wndw->immd->update (wndw, interlock);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 37/155 bpf: fix undefined behavior in narrow load handling
In reply to Greg Kroah-Hartman[ Upstream commit e2f7fc0ac6957cabff4cecf6c721979b571af208 ]
Commit 31fd85816dbe ("bpf: permits narrower load from bpf program context fields") made the verifier add AND instructions to clear the unwanted bits with a mask when doing a narrow load. The mask is computed with
(1 << size * 8) - 1
where "size" is the size of the narrow load. When doing a 4 byte load of a an 8 byte field the verifier shifts the literal 1 by 32 places to the left. This results in an overflow of a signed integer, which is an undefined behavior. Typically, the computed mask was zero, so the result of the narrow load ended up being zero too.
Cast the literal to long long to avoid overflows. Note that narrow load of the 4 byte fields does not have the undefined behavior, because the load size can only be either 1 or 2 bytes, so shifting 1 by 8 or 16 places will not overflow it. And reading 4 bytes would not be a narrow load of a 4 bytes field.
--- kernel/bpf/verifier.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/bpf/verifier.c +1 -1
@@ -7296,7 +7296,7 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env) insn->dst_reg, shift); insn_buf[cnt++] =BPF_ALU64_IMM (BPF_AND , insn->dst_reg, - (1 << size *8 ) -1 ); + (1ULL << size *8 ) -1 ); } }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 38/155 EDAC/mpc85xx: Prevent building as a module
In reply to Greg Kroah-Hartman[ Upstream commit 2b8358a951b1e2a534a54924cd8245e58a1c5fb8 ]
The mpc85xx EDAC driver can be configured as a module but then fails to build because it uses two unexported symbols:
ERROR: ".pci_find_hose_for_OF_device" [drivers/edac/mpc85xx_edac_mod.ko] undefined!
ERROR: ".early_find_capability" [drivers/edac/mpc85xx_edac_mod.ko] undefined!
We don't want to export those symbols just for this driver, so make the driver only configurable as a built-in.
This seems to have been broken since at least
c92132f59806 ("edac/85xx: Add PCIe error interrupt edac support")
(Nov 2013).
[ bp: make it depend on EDAC=y so that the EDAC core doesn't get built
as a module. ]
--- drivers/edac/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/edac/Kconfig +2 -2
@@ -263,8 +263,8 @@ config EDAC_PND2 micro-server but may appear on others in the future. config EDAC_MPC85XX - tristate "Freescale MPC83xx / MPC85xx" - depends on FSL_SOC + bool "Freescale MPC83xx / MPC85xx" + depends on FSL_SOC && EDAC=y help Support for error detection and correction on the Freescale MPC8349, MPC8560, MPC8540, MPC8548, T4240
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 39/155 pwm: meson: Use the spin-lock only to protect register modifications
In reply to Greg Kroah-Hartman[ Upstream commit f173747fffdf037c791405ab4f1ec0eb392fc48e ]
Holding the spin-lock for all of the code in meson_pwm_apply() can result in a "BUG: scheduling while atomic". This can happen because clk_get_rate() (which is called from meson_pwm_calc()) may sleep. Only hold the spin-lock when modifying registers to solve this.
The reason why we need a spin-lock in the driver is because the REG_MISC_AB register is shared between the two channels provided by one PWM controller. The only functions where REG_MISC_AB is modified are meson_pwm_enable() and meson_pwm_disable() so the register reads/writes in there need to be protected by the spin-lock.
The original code also used the spin-lock to protect the values in struct meson_pwm_channel. This could be necessary if two consumers can use the same PWM channel. However, PWM core doesn't allow this so we don't need to protect the values in struct meson_pwm_channel with a lock.
--- drivers/pwm/pwm-meson.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-)
drivers/pwm/pwm-meson.c +17 -8
@@ -111,6 +111,10 @@ struct meson_pwm {const struct meson_pwm_data *data;void __iomem *base;u8 inverter_mask; +/* +* Protects register (write) access to the REG_MISC_AB register +* that is shared between the two PWMs. +*/ spinlock_t lock; };
@@ -235,6 +239,7 @@ static void meson_pwm_enable(struct meson_pwm *meson, {u32 value, clk_shift, clk_enable, enable;unsigned int offset; +unsigned long flags;switch (id) {case 0 :
@@ -255,6 +260,8 @@ static void meson_pwm_enable(struct meson_pwm *meson,return ; } +spin_lock_irqsave (&meson->lock, flags); + value =readl (meson->base +REG_MISC_AB ); value &= ~(MISC_CLK_DIV_MASK << clk_shift); value |= channel->pre_div << clk_shift;
@@ -267,11 +274,14 @@ static void meson_pwm_enable(struct meson_pwm *meson, value =readl (meson->base +REG_MISC_AB ); value |= enable;writel (value, meson->base +REG_MISC_AB ); + +spin_unlock_irqrestore (&meson->lock, flags); }static void meson_pwm_disable (struct meson_pwm *meson,unsigned int id) {u32 value, enable; +unsigned long flags;switch (id) {case 0 :
@@ -286,9 +296,13 @@ static void meson_pwm_disable(struct meson_pwm *meson, unsigned int id)return ; } +spin_lock_irqsave (&meson->lock, flags); + value =readl (meson->base +REG_MISC_AB ); value &= ~enable;writel (value, meson->base +REG_MISC_AB ); + +spin_unlock_irqrestore (&meson->lock, flags); } static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
@@ -296,19 +310,16 @@ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, {struct meson_pwm_channel *channel =pwm_get_chip_data (pwm);struct meson_pwm *meson =to_meson_pwm (chip); -unsigned long flags;int err =0 ;if (!state)return -EINVAL ; -spin_lock_irqsave (&meson->lock, flags); -if (!state->enabled) {meson_pwm_disable (meson, pwm->hwpwm); channel->state.enabled = false; - goto unlock; +return 0 ; } if (state->period != channel->state.period ||
@@ -329,7 +340,7 @@ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, err =meson_pwm_calc (meson, channel, pwm->hwpwm, state->duty_cycle, state->period);if (err <0 ) - goto unlock; +return err; channel->state.polarity = state->polarity; channel->state.period = state->period;
@@ -341,9 +352,7 @@ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, channel->state.enabled = true; } -unlock: -spin_unlock_irqrestore (&meson->lock, flags); -return err; +return 0 ; } static void meson_pwm_get_state(struct pwm_chip *chip, struct pwm_device *pwm,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 40/155 mailbox: stm32-ipcc: check invalid irq
In reply to Greg Kroah-Hartman[ Upstream commit 68a1c8485cf83734d4da9d81cd3b5d2ae7c0339b ]
On failure of_irq_get() returns a negative value or zero, which is not handled as an error in the existing implementation. Instead of using this API, use platform_get_irq() that returns exclusively a negative value on failure.
Also, do not output an error log in case of defer probe error.
--- drivers/mailbox/stm32-ipcc.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
drivers/mailbox/stm32-ipcc.c +8 -5
@@ -8,9 +8,9 @@#include <linux/bitfield.h> #include <linux/clk.h> #include <linux/interrupt.h> +#include <linux/io.h> #include <linux/mailbox_controller.h> #include <linux/module.h> -#include <linux/of_irq.h> #include <linux/platform_device.h> #include <linux/pm_wakeirq.h>
@@ -240,9 +240,11 @@ static int stm32_ipcc_probe(struct platform_device *pdev)/* irq */ for (i =0 ; i <IPCC_IRQ_NUM ; i++) { - ipcc->irqs[i] =of_irq_get_byname (dev->of_node, irq_name[i]); + ipcc->irqs[i] =platform_get_irq_byname (pdev, irq_name[i]);if (ipcc->irqs[i] <0 ) { -dev_err (dev,"no IRQ specified %s\n" , irq_name[i]); +if (ipcc->irqs[i] != -EPROBE_DEFER ) +dev_err (dev,"no IRQ specified %s\n" , + irq_name[i]); ret = ipcc->irqs[i]; goto err_clk; }
@@ -263,9 +265,10 @@ static int stm32_ipcc_probe(struct platform_device *pdev)/* wakeup */ if (of_property_read_bool (np,"wakeup-source" )) { - ipcc->wkp =of_irq_get_byname (dev->of_node,"wakeup" ); + ipcc->wkp =platform_get_irq_byname (pdev,"wakeup" );if (ipcc->wkp <0 ) { -dev_err (dev,"could not get wakeup IRQ\n" ); +if (ipcc->wkp != -EPROBE_DEFER ) +dev_err (dev,"could not get wakeup IRQ\n" ); ret = ipcc->wkp; goto err_clk; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 41/155 ntp: Allow TAI-UTC offset to be set to zero
In reply to Greg Kroah-Hartman[ Upstream commit fdc6bae940ee9eb869e493990540098b8c0fd6ab ]
The ADJ_TAI adjtimex mode sets the TAI-UTC offset of the system clock. It is typically set by NTP/PTP implementations and it is automatically updated by the kernel on leap seconds. The initial value is zero (which applications may interpret as unknown), but this value cannot be set by adjtimex. This limitation seems to go back to the original "nanokernel" implementation by David Mills.
Change the ADJ_TAI check to accept zero as a valid TAI-UTC offset in order to allow setting it back to the initial value.
--- kernel/time/ntp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/time/ntp.c +1 -1
@@ -690,7 +690,7 @@ static inline void process_adjtimex_modes(const struct __kernel_timex *txc, time_constant =max (time_constant,0l ); } -if (txc->modes &ADJ_TAI && txc->constant >0 ) +if (txc->modes &ADJ_TAI && txc->constant >=0 ) *time_tai = txc->constant;if (txc->modes &ADJ_OFFSET )
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 42/155 f2fs: fix to avoid panic in do_recover_data()
In reply to Greg Kroah-Hartman[ Upstream commit 22d61e286e2d9097dae36f75ed48801056b77cac ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203227
- Overview
When mounting the attached crafted image, following errors are reported. Additionally, it hangs on sync after trying to mount it.
The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows.CONFIG_F2FS_FS=yCONFIG_F2FS_STAT_FS=yCONFIG_F2FS_FS_XATTR=yCONFIG_F2FS_FS_POSIX_ACL=yCONFIG_F2FS_CHECK_FS=y
- Reproduces
mkdir test
mount -t f2fs tmp.img test
sync
- Messages
kernel BUG at fs/f2fs/recovery.c:549!
RIP: 0010:recover_data+0x167a/0x1780 Call Trace: f2fs_recover_fsync_data+0x613/0x710 f2fs_fill_super+0x1043/0x1aa0 mount_bdev+0x16d/0x1a0 mount_fs+0x4a/0x170 vfs_kern_mount+0x5d/0x100 do_mount+0x200/0xcf0 ksys_mount+0x79/0xc0 __x64_sys_mount+0x1c/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
During recovery, if ofs_of_node is inconsistent in between recovered node page and original checkpointed node page, let's just fail recovery instead of making kernel panic.
--- fs/f2fs/recovery.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
fs/f2fs/recovery.c +9 -1
@@ -546,7 +546,15 @@ retry_dn: goto err;f2fs_bug_on (sbi, ni.ino !=ino_of_node (page)); -f2fs_bug_on (sbi,ofs_of_node (dn.node_page) !=ofs_of_node (page)); + +if (ofs_of_node (dn.node_page) !=ofs_of_node (page)) { +f2fs_msg (sbi->sb,KERN_WARNING , +"Inconsistent ofs_of_node, ino:%lu, ofs:%u, %u" , + inode->i_ino,ofs_of_node (dn.node_page), +ofs_of_node (page)); + err = -EFAULT ; + goto err; + }for (; start < end; start++, dn.ofs_in_node++) {block_t src, dest;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 43/155 f2fs: fix to avoid panic in f2fs_inplace_write_data()
In reply to Greg Kroah-Hartman[ Upstream commit 05573d6ccf702df549a7bdeabef31e4753df1a90 ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203239
- Overview
When mounting the attached crafted image and running program, following errors are reported. Additionally, it hangs on sync after running program.
The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows.CONFIG_F2FS_FS=yCONFIG_F2FS_STAT_FS=yCONFIG_F2FS_FS_XATTR=yCONFIG_F2FS_FS_POSIX_ACL=yCONFIG_F2FS_CHECK_FS=y
- Reproduces
cc poc_15.c
./run.sh f2fs
sync
- Kernel messages
------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:3162! RIP: 0010:f2fs_inplace_write_data+0x12d/0x160 Call Trace: f2fs_do_write_data_page+0x3c1/0x820 __write_data_page+0x156/0x720 f2fs_write_cache_pages+0x20d/0x460 f2fs_write_data_pages+0x1b4/0x300 do_writepages+0x15/0x60 __filemap_fdatawrite_range+0x7c/0xb0 file_write_and_wait_range+0x2c/0x80 f2fs_do_sync_file+0x102/0x810 do_fsync+0x33/0x60 __x64_sys_fsync+0xb/0x10 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
The reason is f2fs_inplace_write_data() will trigger kernel panic due to data block locates in node type segment.
To avoid panic, let's just return error code and set SBI_NEED_FSCK to give a hint to fsck for latter repairing.
--- fs/f2fs/segment.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
fs/f2fs/segment.c +7 -2
@@ -3188,13 +3188,18 @@ int f2fs_inplace_write_data(struct f2fs_io_info *fio) {int err;struct f2fs_sb_info *sbi = fio->sbi; +unsigned int segno; fio->new_blkaddr = fio->old_blkaddr;/* i/o temperature is needed for passing down write hints */ __get_segment_type (fio); -f2fs_bug_on (sbi, !IS_DATASEG (get_seg_entry (sbi, -GET_SEGNO (sbi, fio->new_blkaddr))->type)); + segno =GET_SEGNO (sbi, fio->new_blkaddr); + +if (!IS_DATASEG (get_seg_entry (sbi, segno)->type)) { +set_sbi_flag (sbi,SBI_NEED_FSCK ); +return -EFAULT ; + }stat_inc_inplace_blocks (fio->sbi);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 44/155 f2fs: fix error path of recovery
In reply to Greg Kroah-Hartman[ Upstream commit 988385795c7f46b231982d54750587f204bd558b ]
There are some places in where we missed to unlock page or unlock page incorrectly, fix them.
--- fs/f2fs/recovery.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
fs/f2fs/recovery.c +11 -4
@@ -325,8 +325,10 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, struct list_head *head,break ; } -if (!is_recoverable_dnode (page)) +if (!is_recoverable_dnode (page)) { +f2fs_put_page (page,1 );break ; + }if (!is_fsync_dnode (page)) goto next;
@@ -338,8 +340,10 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, struct list_head *head,if (!check_only &&IS_INODE (page) &&is_dent_dnode (page)) { err =f2fs_recover_inode_page (sbi, page); -if (err) +if (err) { +f2fs_put_page (page,1 );break ; + } quota_inode = true; }
@@ -355,6 +359,7 @@ static int find_fsync_dnodes(struct f2fs_sb_info *sbi, struct list_head *head, err =0 ; goto next; } +f2fs_put_page (page,1 );break ; } }
@@ -370,6 +375,7 @@ next:"%s: detect looped node chain, " "blkaddr:%u, next:%u" , __func__, blkaddr, next_blkaddr_of_node(page)); +f2fs_put_page (page,1 ); err = -EINVAL ;break ; }
@@ -380,7 +386,6 @@ next:f2fs_ra_meta_pages_cond (sbi, blkaddr); } -f2fs_put_page (page,1 );return err; }
@@ -674,8 +679,10 @@ static int recover_data(struct f2fs_sb_info *sbi, struct list_head *inode_list,*/ if (IS_INODE (page)) { err =recover_inode (entry->inode, page); -if (err) +if (err) { +f2fs_put_page (page,1 );break ; + } }if (entry->last_dentry == blkaddr) { err =recover_dentry (entry->inode, page, dir_list);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 45/155 f2fs: fix to avoid panic in f2fs_remove_inode_page()
In reply to Greg Kroah-Hartman[ Upstream commit 8b6810f8acfe429fde7c7dad4714692cc5f75651 ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203219
- Overview
When mounting the attached crafted image and running program, I got this error. Additionally, it hangs on sync after running the program.
The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
- Reproduces
cc poc_06.c
mkdir test
mount -t f2fs tmp.img test
cp a.out test
cd test
sudo ./a.out
sync
- Messages
kernel BUG at fs/f2fs/node.c:1183!
RIP: 0010:f2fs_remove_inode_page+0x294/0x2d0 Call Trace: f2fs_evict_inode+0x2a3/0x3a0 evict+0xba/0x180 __dentry_kill+0xbe/0x160 dentry_kill+0x46/0x180 dput+0xbb/0x100 do_renameat2+0x3c9/0x550 __x64_sys_rename+0x17/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
The reason is f2fs_remove_inode_page() will trigger kernel panic due to inconsistent i_blocks value of inode.
To avoid panic, let's just print debug message and set SBI_NEED_FSCK to give a hint to fsck for latter repairing of potential image corruption.
--- fs/f2fs/node.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
fs/f2fs/node.c +8 -2
@@ -1179,8 +1179,14 @@ int f2fs_remove_inode_page(struct inode *inode)f2fs_put_dnode (&dn);return -EIO ; } -f2fs_bug_on (F2FS_I_SB (inode), - inode->i_blocks !=0 && inode->i_blocks !=8 ); + +if (unlikely (inode->i_blocks !=0 && inode->i_blocks !=8 )) { +f2fs_msg (F2FS_I_SB (inode)->sb,KERN_WARNING , +"Inconsistent i_blocks, ino:%lu, iblocks:%llu" , + inode->i_ino, + (unsigned long long )inode->i_blocks); +set_sbi_flag (F2FS_I_SB (inode),SBI_NEED_FSCK ); + }/* will put inode & node pages */ err =truncate_node (&dn);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 46/155 f2fs: fix to do sanity check on free nid
In reply to Greg Kroah-Hartman[ Upstream commit 626bcf2b7ce87211dba565f2bfa7842ba5be5c1b ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203225
- Overview
When mounting the attached crafted image and unmounting it, following errors are reported. Additionally, it hangs on sync after unmounting.
The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows.CONFIG_F2FS_FS=yCONFIG_F2FS_STAT_FS=yCONFIG_F2FS_FS_XATTR=yCONFIG_F2FS_FS_POSIX_ACL=yCONFIG_F2FS_CHECK_FS=y
- Reproduces
mkdir test
mount -t f2fs tmp.img test
touch test/t
umount test
sync
- Messages
kernel BUG at fs/f2fs/node.c:3073!
RIP: 0010:f2fs_destroy_node_manager+0x2f0/0x300 Call Trace: f2fs_put_super+0xf4/0x270 generic_shutdown_super+0x62/0x110 kill_block_super+0x1c/0x50 kill_f2fs_super+0xad/0xd0 deactivate_locked_super+0x35/0x60 cleanup_mnt+0x36/0x70 task_work_run+0x75/0x90 exit_to_usermode_loop+0x93/0xa0 do_syscall_64+0xba/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0010:f2fs_destroy_node_manager+0x2f0/0x300
NAT table is corrupted, so reserved meta/node inode ids were added into free list incorrectly, during file creation, since reserved id has cached in inode hash, so it fails the creation and preallocated nid can not be released later, result in kernel panic.
To fix this issue, let's do nid boundary check during free nid loading.
--- fs/f2fs/node.c | 3 +++ 1 file changed, 3 insertions(+)
fs/f2fs/node.c +3 -0
@@ -2082,6 +2082,9 @@ static bool add_free_nid(struct f2fs_sb_info *sbi,if (unlikely (nid ==0 ))return false; +if (unlikely (f2fs_check_nid_range (sbi, nid))) +return false; + i =f2fs_kmem_cache_alloc (free_nid_slab,GFP_NOFS ); i->nid = nid; i->state =FREE_NID ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 47/155 f2fs: fix to clear dirty inode in error path of f2fs_iget()
In reply to Greg Kroah-Hartman[ Upstream commit 546d22f070d64a7b96f57c93333772085d3a5e6d ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203217
- Overview
When mounting the attached crafted image and running program, I got this error. Additionally, it hangs on sync after running the program.
The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
- Reproduces
cc poc_test_05.c
mkdir test
mount -t f2fs tmp.img test
sudo ./a.out
sync
- Messages
kernel BUG at fs/f2fs/inode.c:707!
RIP: 0010:f2fs_evict_inode+0x33f/0x3a0 Call Trace: evict+0xba/0x180 f2fs_iget+0x598/0xdf0 f2fs_lookup+0x136/0x320 __lookup_slow+0x92/0x140 lookup_slow+0x30/0x50 walk_component+0x1c1/0x350 path_lookupat+0x62/0x200 filename_lookup+0xb3/0x1a0 do_readlinkat+0x56/0x110 __x64_sys_readlink+0x16/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
During inode loading, __recover_inline_status() can recovery inode status and set inode dirty, once we failed in following process, it will fail the check in f2fs_evict_inode, result in trigger BUG_ON().
Let's clear dirty inode in error path of f2fs_iget() to avoid panic.
--- fs/f2fs/inode.c | 1 + 1 file changed, 1 insertion(+)
fs/f2fs/inode.c +1 -0
@@ -488,6 +488,7 @@ make_now:return inode; bad_inode: +f2fs_inode_synced (inode);iget_failed (inode);trace_f2fs_iget_exit (inode, ret);return ERR_PTR (ret);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 48/155 f2fs: fix to avoid panic in dec_valid_block_count()
In reply to Greg Kroah-Hartman[ Upstream commit 5e159cd349bf3a31fb7e35c23a93308eb30f4f71 ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203209
- Overview
When mounting the attached crafted image and running program, I got this error. Additionally, it hangs on sync after the this script.
The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
- Reproduces
cc poc_01.c
./run.sh f2fs
sync
kernel BUG at fs/f2fs/f2fs.h:1788!
RIP: 0010:f2fs_truncate_data_blocks_range+0x342/0x350 Call Trace: f2fs_truncate_blocks+0x36d/0x3c0 f2fs_truncate+0x88/0x110 f2fs_setattr+0x3e1/0x460 notify_change+0x2da/0x400 do_truncate+0x6d/0xb0 do_sys_ftruncate+0xf1/0x160 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
The reason is dec_valid_block_count() will trigger kernel panic due to inconsistent count in between inode.i_blocks and actual block.
To avoid panic, let's just print debug message and set SBI_NEED_FSCK to give a hint to fsck for latter repairing.
--- fs/f2fs/f2fs.h | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
fs/f2fs/f2fs.h +10 -2
@@ -1789,6 +1789,7 @@ enospc:return -ENOSPC ; } +void f2fs_msg (struct super_block *sb,const char *level,const char *fmt, ...);static inline void dec_valid_block_count (struct f2fs_sb_info *sbi,struct inode *inode,block_t count)
@@ -1797,13 +1798,21 @@ static inline void dec_valid_block_count(struct f2fs_sb_info *sbi,spin_lock (&sbi->stat_lock);f2fs_bug_on (sbi, sbi->total_valid_block_count < (block_t ) count); -f2fs_bug_on (sbi, inode->i_blocks < sectors); sbi->total_valid_block_count -= (block_t )count;if (sbi->reserved_blocks && sbi->current_reserved_blocks < sbi->reserved_blocks) sbi->current_reserved_blocks =min (sbi->reserved_blocks, sbi->current_reserved_blocks + count);spin_unlock (&sbi->stat_lock); +if (unlikely (inode->i_blocks < sectors)) { +f2fs_msg (sbi->sb,KERN_WARNING , +"Inconsistent i_blocks, ino:%lu, iblocks:%llu, sectors:%llu" , + inode->i_ino, + (unsigned long long )inode->i_blocks, + (unsigned long long )sectors); +set_sbi_flag (sbi,SBI_NEED_FSCK ); +return ; + }f2fs_i_blocks_write (inode, count, false, true); }
@@ -2817,7 +2826,6 @@ static inline void f2fs_update_iostat(struct f2fs_sb_info *sbi,bool f2fs_is_valid_blkaddr (struct f2fs_sb_info *sbi,block_t blkaddr,int type); -void f2fs_msg (struct super_block *sb,const char *level,const char *fmt, ...);static inline void verify_blkaddr (struct f2fs_sb_info *sbi,block_t blkaddr,int type) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 49/155 f2fs: fix to use inline space only if inline_xattr is enable
In reply to Greg Kroah-Hartman[ Upstream commit 622927f3b8809206f6da54a6a7ed4df1a7770fce ]
With below mkfs and mount option:
MKFS_OPTIONS -- -O extra_attr -O project_quota -O inode_checksum -O flexible_inline_xattr -O inode_crtime -f MOUNT_OPTIONS -- -o noinline_xattr
We may miss xattr data with below testcase:
- mkdir dir
- setfattr -n "user.name" -v 0 dir
- for ((i = 0; i < 190; i++)) do touch dir/$i; done
- umount
- mount
- getfattr -n "user.name" dir
user.name: No such attribute
The root cause is that we persist xattr data into reserved inline xattr space, even if inline_xattr is not enable in inline directory inode, after inline dentry conversion, reserved space no longer exists, so that xattr data missed.
Let's use inline xattr space only if inline_xattr flag is set on inode to fix this iusse.
--- fs/f2fs/f2fs.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/f2fs/f2fs.h +3 -1
@@ -2579,7 +2579,9 @@ static inline void *inline_xattr_addr(struct inode *inode, struct page *page)static inline int inline_xattr_size (struct inode *inode) { -return get_inline_xattr_addrs (inode) *sizeof (__le32); +if (f2fs_has_inline_xattr (inode)) +return get_inline_xattr_addrs (inode) *sizeof (__le32); +return 0 ; }static inline int f2fs_has_inline_data (struct inode *inode)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 50/155 f2fs: fix to avoid panic in dec_valid_node_count()
In reply to Greg Kroah-Hartman[ Upstream commit ea6d7e72fea49402aa445345aade7a26b81732e3 ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203213
- Overview
When mounting the attached crafted image and running program, I got this error. Additionally, it hangs on sync after running the this script.
The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
- Reproduces
mkdir test
mount -t f2fs tmp.img test
cp a.out test
cd test
sudo ./a.out
sync
kernel BUG at fs/f2fs/f2fs.h:2012!
RIP: 0010:truncate_node+0x2c9/0x2e0 Call Trace: f2fs_truncate_xattr_node+0xa1/0x130 f2fs_remove_inode_page+0x82/0x2d0 f2fs_evict_inode+0x2a3/0x3a0 evict+0xba/0x180 __dentry_kill+0xbe/0x160 dentry_kill+0x46/0x180 dput+0xbb/0x100 do_renameat2+0x3c9/0x550 __x64_sys_rename+0x17/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
The reason is dec_valid_node_count() will trigger kernel panic due to inconsistent count in between inode.i_blocks and actual block.
To avoid panic, let's just print debug message and set SBI_NEED_FSCK to give a hint to fsck for latter repairing.
--- fs/f2fs/f2fs.h | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)
fs/f2fs/f2fs.h +11 -3
@@ -2029,7 +2029,6 @@ static inline void dec_valid_node_count(struct f2fs_sb_info *sbi,f2fs_bug_on (sbi, !sbi->total_valid_block_count);f2fs_bug_on (sbi, !sbi->total_valid_node_count); -f2fs_bug_on (sbi, !is_inode && !inode->i_blocks); sbi->total_valid_node_count--; sbi->total_valid_block_count--;
@@ -2039,10 +2038,19 @@ static inline void dec_valid_node_count(struct f2fs_sb_info *sbi,spin_unlock (&sbi->stat_lock); -if (is_inode) +if (is_inode) {dquot_free_inode (inode); -else + }else { +if (unlikely (inode->i_blocks ==0 )) { +f2fs_msg (sbi->sb,KERN_WARNING , +"Inconsistent i_blocks, ino:%lu, iblocks:%llu" , + inode->i_ino, + (unsigned long long )inode->i_blocks); +set_sbi_flag (sbi,SBI_NEED_FSCK ); +return ; + }f2fs_i_blocks_write (inode,1 , false, true); + } }static inline unsigned int valid_node_count (struct f2fs_sb_info *sbi)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 51/155 f2fs: fix to do sanity check on valid block count of segment
In reply to Greg Kroah-Hartman[ Upstream commit e95bcdb2fefa129f37bd9035af1d234ca92ee4ef ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203233
- Overview
When mounting the attached crafted image and running program, following errors are reported. Additionally, it hangs on sync after running program.
The image is intentionally fuzzed from a normal f2fs image for testing. Compile options for F2FS are as follows.CONFIG_F2FS_FS=yCONFIG_F2FS_STAT_FS=yCONFIG_F2FS_FS_XATTR=yCONFIG_F2FS_FS_POSIX_ACL=yCONFIG_F2FS_CHECK_FS=y
- Reproduces
cc poc_13.c
mkdir test
mount -t f2fs tmp.img test
cp a.out test
cd test
sudo ./a.out
sync
- Kernel messages
F2FS-fs (sdb): Bitmap was wrongly set, blk:4608
kernel BUG at fs/f2fs/segment.c:2102!
RIP: 0010:update_sit_entry+0x394/0x410 Call Trace: f2fs_allocate_data_block+0x16f/0x660 do_write_page+0x62/0x170 f2fs_do_write_node_page+0x33/0xa0 __write_node_page+0x270/0x4e0 f2fs_sync_node_pages+0x5df/0x670 f2fs_write_checkpoint+0x372/0x1400 f2fs_sync_fs+0xa3/0x130 f2fs_do_sync_file+0x1a6/0x810 do_fsync+0x33/0x60 __x64_sys_fsync+0xb/0x10 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
sit.vblocks and sum valid block count in sit.valid_map may be inconsistent, segment w/ zero vblocks will be treated as free segment, while allocating in free segment, we may allocate a free block, if its bitmap is valid previously, it can cause kernel crash due to bitmap verification failure.
Anyway, to avoid further serious metadata inconsistence and corruption, it is necessary and worth to detect SIT inconsistence. So let's enable check_block_count() to verify vblocks and valid_map all the time rather than do it only CONFIG_F2FS_CHECK_FS is enabled.
--- fs/f2fs/segment.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
fs/f2fs/segment.h +1 -2
@@ -672,7 +672,6 @@ static inline void verify_block_addr(struct f2fs_io_info *fio, block_t blk_addr)static inline int check_block_count (struct f2fs_sb_info *sbi,int segno,struct f2fs_sit_entry *raw_sit) { -#ifdef CONFIG_F2FS_CHECK_FS bool is_valid =test_bit_le (0 , raw_sit->valid_map) ? true : false;int valid_blocks =0 ;int cur_pos =0 , next_pos;
@@ -699,7 +698,7 @@ static inline int check_block_count(struct f2fs_sb_info *sbi,set_sbi_flag (sbi,SBI_NEED_FSCK );return -EINVAL ; } -#endif +/* check segment usage, and check boundary of a given segment number */ if (unlikely (GET_SIT_VBLOCKS (raw_sit) > sbi->blocks_per_seg || segno >TOTAL_SEGS (sbi) -1 )) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 52/155 f2fs: fix to avoid deadloop in foreground GC
In reply to Greg Kroah-Hartman[ Upstream commit 793ab1c8a792f8bccd7ae4c5be02bd275410b3af ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203211
- Overview
When mounting the attached crafted image and making a new file, I got this error and the error messages keep repeating.
The image is intentionally fuzzed from a normal f2fs image for testing and I run with option CONFIG_F2FS_CHECK_FS on.
- Reproduces
mkdir test
mount -t f2fs tmp.img test
cd test
touch t
- Messages
[ 58.820451] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.821485] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.822530] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.823571] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.824616] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.825640] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.826663] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.827698] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.828719] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.829759] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.830783] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.831828] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.832869] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.833888] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.834945] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.835996] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.837028] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.838051] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.839072] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.840100] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.841147] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.842186] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.843214] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.844267] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.845282] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.846305] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT [ 58.847341] F2FS-fs (sdb): Inconsistent segment (1) type [1, 0] in SSA and SIT
... (repeating)
During GC, if segment type stored in SSA and SIT is inconsistent, we just skip migrating current segment directly, since we need to know the exact type to decide the migration function we use.
So in foreground GC, we will easily run into a infinite loop as we may select the same victim segment which has inconsistent type due to greedy policy. In order to end up this, we choose to shutdown filesystem. For backgrond GC, we need to do that as well, so that we can avoid latter potential infinite looped foreground GC.
--- fs/f2fs/gc.c | 1 + 1 file changed, 1 insertion(+)
fs/f2fs/gc.c +1 -0
@@ -1175,6 +1175,7 @@ static int do_garbage_collect(struct f2fs_sb_info *sbi,"type [%d, %d] in SSA and SIT" , segno, type, GET_SUM_TYPE((&sum->footer)));set_sbi_flag (sbi,SBI_NEED_FSCK ); +f2fs_stop_checkpoint (sbi, false); goto skip; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 53/155 f2fs: fix to retrieve inline xattr space
In reply to Greg Kroah-Hartman[ Upstream commit 45a746881576977f85504c21a75547f10c5c0a8e ]
With below mkfs and mount option, generic/339 of fstest will report that scratch image becomes corrupted.
MKFS_OPTIONS -- -O extra_attr -O project_quota -O inode_checksum -O flexible_inline_xattr -O inode_crtime -f /dev/zram1 MOUNT_OPTIONS -- -o acl,user_xattr -o discard,noinline_xattr /dev/zram1 /mnt/scratch_f2fs
[ASSERT] (f2fs_check_dirent_position:1315) --> Wrong position of dirent pino:1970, name: (...) level:8, dir_level:0, pgofs:951, correct range:[900, 901]
In old kernel, inline data and directory always reserved 200 bytes in inode layout, even if inline_xattr is disabled, then new kernel tries to retrieve that space for non-inline xattr inode, but for inline dentry, its layout size should be fixed, so we just keep that reserved space.
But the problem here is that, after inline dentry conversion, inline dentry layout no longer exists, if we still reserve inline xattr space, after dents updates, there will be a hole in inline xattr space, which can break hierarchy hash directory structure.
This patch fixes this issue by retrieving inline xattr space after inline dentry conversion.
--- fs/f2fs/inline.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+)
fs/f2fs/inline.c +17 -0
@@ -420,6 +420,14 @@ static int f2fs_move_inline_dirents(struct inode *dir, struct page *ipage,stat_dec_inline_dir (dir);clear_inode_flag (dir,FI_INLINE_DENTRY ); +/* +* should retrieve reserved space which was used to keep +* inline_dentry's structure for backward compatibility. +*/ +if (!f2fs_sb_has_flexible_inline_xattr (F2FS_I_SB (dir)) && + !f2fs_has_inline_xattr (dir)) +F2FS_I (dir)->i_inline_xattr_size =0 ; +f2fs_i_depth_write (dir,1 );if (i_size_read (dir) <PAGE_SIZE )f2fs_i_size_write (dir,PAGE_SIZE );
@@ -501,6 +509,15 @@ static int f2fs_move_rehashed_dirents(struct inode *dir, struct page *ipage,stat_dec_inline_dir (dir);clear_inode_flag (dir,FI_INLINE_DENTRY ); + +/* +* should retrieve reserved space which was used to keep +* inline_dentry's structure for backward compatibility. +*/ +if (!f2fs_sb_has_flexible_inline_xattr (F2FS_I_SB (dir)) && + !f2fs_has_inline_xattr (dir)) +F2FS_I (dir)->i_inline_xattr_size =0 ; +kvfree (backup_dentry);return 0 ; recover:
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 54/155 f2fs: fix to do checksum even if inode page is uptodate
In reply to Greg Kroah-Hartman[ Upstream commit b42b179bda9ff11075a6fc2bac4d9e400513679a ]
As Jungyeon reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=203221
- Overview
When mounting the attached crafted image and running program, this error is reported.
The image is intentionally fuzzed from a normal f2fs image for testing and I enabled option CONFIG_F2FS_CHECK_FS on.
- Reproduces
cc poc_07.c
mkdir test
mount -t f2fs tmp.img test
cp a.out test
cd test
sudo ./a.out
- Messages
kernel BUG at fs/f2fs/node.c:1279!
RIP: 0010:read_node_page+0xcf/0xf0 Call Trace: __get_node_page+0x6b/0x2f0 f2fs_iget+0x8f/0xdf0 f2fs_lookup+0x136/0x320 __lookup_slow+0x92/0x140 lookup_slow+0x30/0x50 walk_component+0x1c1/0x350 path_lookupat+0x62/0x200 filename_lookup+0xb3/0x1a0 do_fchmodat+0x3e/0xa0 __x64_sys_chmod+0x12/0x20 do_syscall_64+0x43/0xf0 entry_SYSCALL_64_after_hwframe+0x44/0xa9
On below paths, we can have opportunity to readahead inode page
- gc_node_segment -> f2fs_ra_node_page
- gc_data_segment -> f2fs_ra_node_page
- f2fs_fill_dentries -> f2fs_ra_node_page
Unlike synchronized read, on readahead path, we can set page uptodate before verifying page's checksum, then read_node_page() will trigger kernel panic once it encounters a uptodated page w/ incorrect checksum.
So considering readahead scenario, we have to do checksum each time when loading inode page even if it is uptodated.
--- fs/f2fs/inode.c | 4 ++-- fs/f2fs/node.c | 7 ++++--- 2 files changed, 6 insertions(+), 5 deletions(-)
fs/f2fs/inode.c +2 -2
@@ -177,8 +177,8 @@ bool f2fs_inode_chksum_verify(struct f2fs_sb_info *sbi, struct page *page)if (provided != calculated)f2fs_msg (sbi->sb,KERN_WARNING , -"checksum invalid, ino = %x, %x vs. %x" , -ino_of_node (page), provided, calculated); +"checksum invalid, nid = %lu, ino_of_node = %x, %x vs. %x" , + page->index,ino_of_node (page), provided, calculated);return provided == calculated; }
fs/f2fs/node.c +4 -3
@@ -1281,9 +1281,10 @@ static int read_node_page(struct page *page, int op_flags)int err;if (PageUptodate (page)) { -#ifdef CONFIG_F2FS_CHECK_FS -f2fs_bug_on (sbi, !f2fs_inode_chksum_verify (sbi, page)); -#endif +if (!f2fs_inode_chksum_verify (sbi, page)) { +ClearPageUptodate (page); +return -EBADMSG ; + }return LOCKED_PAGE ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 55/155 media: atmel: atmel-isc: fix asd memory allocation
In reply to Greg Kroah-Hartman[ Upstream commit 1e4e25c4959c10728fbfcc6a286f9503d32dfe02 ]
The subsystem will free the asd memory on notifier cleanup, if the asd is added to the notifier.
However the memory is freed using kfree.
Thus, we cannot allocate the asd using devm_*
This can lead to crashes and problems.
To test this issue, just return an error at probe, but cleanup the notifier beforehand.
--- drivers/media/platform/atmel/atmel-isc.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/media/platform/atmel/atmel-isc.c +6 -2
@@ -2065,8 +2065,11 @@ static int isc_parse_dt(struct device *dev, struct isc_device *isc)break ; } - subdev_entity->asd =devm_kzalloc (dev, -sizeof (*subdev_entity->asd),GFP_KERNEL ); +/* asd will be freed by the subsystem once it's added to the +* notifier list +*/ + subdev_entity->asd =kzalloc (sizeof (*subdev_entity->asd), +GFP_KERNEL );if (!subdev_entity->asd) {of_node_put (rem); ret = -ENOMEM ;
@@ -2210,6 +2213,7 @@ static int atmel_isc_probe(struct platform_device *pdev) subdev_entity->asd);if (ret) {fwnode_handle_put (subdev_entity->asd->match.fwnode); +kfree (subdev_entity->asd); goto cleanup_subdev; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 56/155 percpu: remove spurious lock dependency between percpu and sched
In reply to Greg Kroah-Hartman[ Upstream commit 198790d9a3aeaef5792d33a560020861126edc22 ]
In free_percpu() we sometimes call pcpu_schedule_balance_work() to queue a work item (which does a wakeup) while holding pcpu_lock. This creates an unnecessary lock dependency between pcpu_lock and the scheduler's pi_lock. There are other places where we call pcpu_schedule_balance_work() without hold pcpu_lock, and this case doesn't need to be different.
Moving the call outside the lock prevents the following lockdep splat when running tools/testing/selftests/bpf/{test_maps,test_progs} in sequence with lockdep enabled:
======================================================
WARNING: possible circular locking dependency detected 5.1.0-dbg-DEV #1 Not tainted
------------------------------------------------------
kworker/23:255/18872 is trying to acquire lock:000000000bc79290 (&(&pool->lock)->rlock){-.-.}, at: __queue_work+0xb2/0x520
but task is already holding lock:00000000e3e7a6aa (pcpu_lock){..-.}, at: free_percpu+0x36/0x260
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #4 (pcpu_lock){..-.}:
lock_acquire+0x9e/0x180
_raw_spin_lock_irqsave+0x3a/0x50
pcpu_alloc+0xfa/0x780
__alloc_percpu_gfp+0x12/0x20
alloc_htab_elem+0x184/0x2b0
__htab_percpu_map_update_elem+0x252/0x290
bpf_percpu_hash_update+0x7c/0x130
__do_sys_bpf+0x1912/0x1be0
__x64_sys_bpf+0x1a/0x20
do_syscall_64+0x59/0x400
entry_SYSCALL_64_after_hwframe+0x49/0xbe-> #3 (&htab->buckets[i].lock){....}:
lock_acquire+0x9e/0x180
_raw_spin_lock_irqsave+0x3a/0x50
htab_map_update_elem+0x1af/0x3a0-> #2 (&rq->lock){-.-.}:
lock_acquire+0x9e/0x180
_raw_spin_lock+0x2f/0x40
task_fork_fair+0x37/0x160
sched_fork+0x211/0x310
copy_process.part.43+0x7b1/0x2160
_do_fork+0xda/0x6b0
kernel_thread+0x29/0x30
rest_init+0x22/0x260
arch_call_rest_init+0xe/0x10
start_kernel+0x4fd/0x520
x86_64_start_reservations+0x24/0x26
x86_64_start_kernel+0x6f/0x72
secondary_startup_64+0xa4/0xb0-> #1 (&p->pi_lock){-.-.}:
lock_acquire+0x9e/0x180
_raw_spin_lock_irqsave+0x3a/0x50
try_to_wake_up+0x41/0x600
wake_up_process+0x15/0x20
create_worker+0x16b/0x1e0
workqueue_init+0x279/0x2ee
kernel_init_freeable+0xf7/0x288
kernel_init+0xf/0x180
ret_from_fork+0x24/0x30-> #0 (&(&pool->lock)->rlock){-.-.}:
__lock_acquire+0x101f/0x12a0
lock_acquire+0x9e/0x180
_raw_spin_lock+0x2f/0x40
__queue_work+0xb2/0x520
queue_work_on+0x38/0x80
free_percpu+0x221/0x260
pcpu_freelist_destroy+0x11/0x20
stack_map_free+0x2a/0x40
bpf_map_free_deferred+0x3c/0x50
process_one_work+0x1f7/0x580
worker_thread+0x54/0x410
kthread+0x10f/0x150
ret_from_fork+0x24/0x30other info that might help us debug this:
Chain exists of: &(&pool->lock)->rlock --> &htab->buckets[i].lock --> pcpu_lock Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(pcpu_lock);
lock(&htab->buckets[i].lock);
lock(pcpu_lock);lock(&(&pool->lock)->rlock);
*** DEADLOCK ***
3 locks held by kworker/23:255/18872:
#0: 00000000b36a6e16 ((wq_completion)events){+.+.},
at: process_one_work+0x17a/0x580
#1: 00000000dfd966f0 ((work_completion)(&map->work)){+.+.},
at: process_one_work+0x17a/0x580
#2: 00000000e3e7a6aa (pcpu_lock){..-.},
at: free_percpu+0x36/0x260stack backtrace: CPU: 23 PID: 18872 Comm: kworker/23:255 Not tainted 5.1.0-dbg-DEV #1 Hardware name: ... Workqueue: events bpf_map_free_deferred Call Trace: dump_stack+0x67/0x95 print_circular_bug.isra.38+0x1c6/0x220 check_prev_add.constprop.50+0x9f6/0xd20 __lock_acquire+0x101f/0x12a0 lock_acquire+0x9e/0x180 _raw_spin_lock+0x2f/0x40 __queue_work+0xb2/0x520 queue_work_on+0x38/0x80 free_percpu+0x221/0x260 pcpu_freelist_destroy+0x11/0x20 stack_map_free+0x2a/0x40 bpf_map_free_deferred+0x3c/0x50 process_one_work+0x1f7/0x580 worker_thread+0x54/0x410 kthread+0x10f/0x150 ret_from_fork+0x24/0x30
--- mm/percpu.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
mm/percpu.c +5 -1
@@ -1738,6 +1738,7 @@ void free_percpu(void __percpu *ptr)struct pcpu_chunk *chunk;unsigned long flags;int off; +bool need_balance = false;if (!ptr)return ;
@@ -1759,7 +1760,7 @@ void free_percpu(void __percpu *ptr)list_for_each_entry (pos, &pcpu_slot[pcpu_nr_slots -1 ], list)if (pos != chunk) { -pcpu_schedule_balance_work (); + need_balance = true;break ; } }
@@ -1767,6 +1768,9 @@ void free_percpu(void __percpu *ptr)trace_percpu_free_percpu (chunk->base_addr, off, ptr);spin_unlock_irqrestore (&pcpu_lock, flags); + +if (need_balance) +pcpu_schedule_balance_work (); }EXPORT_SYMBOL_GPL (free_percpu);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 57/155 configfs: fix possible use-after-free in configfs_register_group
In reply to Greg Kroah-Hartman[ Upstream commit 35399f87e271f7cf3048eab00a421a6519ac8441 ]
In configfs_register_group(), if create_default_group() failed, we forget to unlink the group. It will left a invalid item in the parent list, which may trigger the use-after-free issue seen below:
BUG: KASAN: use-after-free in __list_add_valid+0xd4/0xe0 lib/list_debug.c:26
Read of size 8 at addr ffff8881ef61ae20 by task syz-executor.0/5996
CPU: 1 PID: 5996 Comm: syz-executor.0 Tainted: G C 5.0.0+ #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xa9/0x10e lib/dump_stack.c:113
print_address_description+0x65/0x270 mm/kasan/report.c:187
kasan_report+0x149/0x18d mm/kasan/report.c:317
__list_add_valid+0xd4/0xe0 lib/list_debug.c:26
__list_add include/linux/list.h:60 [inline]
list_add_tail include/linux/list.h:93 [inline]
link_obj+0xb0/0x190 fs/configfs/dir.c:759
link_group+0x1c/0x130 fs/configfs/dir.c:784
configfs_register_group+0x56/0x1e0 fs/configfs/dir.c:1751
configfs_register_default_group+0x72/0xc0 fs/configfs/dir.c:1834
? 0xffffffffc1be0000
iio_sw_trigger_init+0x23/0x1000 [industrialio_sw_trigger]
do_one_initcall+0xbc/0x47d init/main.c:887
do_init_module+0x1b5/0x547 kernel/module.c:3456
load_module+0x6405/0x8c10 kernel/module.c:3804
__do_sys_finit_module+0x162/0x190 kernel/module.c:3898
do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x462e99
Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f494ecbcc58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99
RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003
RBP: 00007f494ecbcc70 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f494ecbd6bc
R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004
Allocated by task 5987:
set_track mm/kasan/common.c:87 [inline]
__kasan_kmalloc.constprop.3+0xa0/0xd0 mm/kasan/common.c:497
kmalloc include/linux/slab.h:545 [inline]
kzalloc include/linux/slab.h:740 [inline]
configfs_register_default_group+0x4c/0xc0 fs/configfs/dir.c:1829
0xffffffffc1bd0023
do_one_initcall+0xbc/0x47d init/main.c:887
do_init_module+0x1b5/0x547 kernel/module.c:3456
load_module+0x6405/0x8c10 kernel/module.c:3804
__do_sys_finit_module+0x162/0x190 kernel/module.c:3898
do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 5987:
set_track mm/kasan/common.c:87 [inline]
__kasan_slab_free+0x130/0x180 mm/kasan/common.c:459
slab_free_hook mm/slub.c:1429 [inline]
slab_free_freelist_hook mm/slub.c:1456 [inline]
slab_free mm/slub.c:3003 [inline]
kfree+0xe1/0x270 mm/slub.c:3955
configfs_register_default_group+0x9a/0xc0 fs/configfs/dir.c:1836
0xffffffffc1bd0023
do_one_initcall+0xbc/0x47d init/main.c:887
do_init_module+0x1b5/0x547 kernel/module.c:3456
load_module+0x6405/0x8c10 kernel/module.c:3804
__do_sys_finit_module+0x162/0x190 kernel/module.c:3898
do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8881ef61ae00
which belongs to the cache kmalloc-192 of size 192
The buggy address is located 32 bytes inside of
192-byte region [ffff8881ef61ae00, ffff8881ef61aec0)
The buggy address belongs to the page:
page:ffffea0007bd8680 count:1 mapcount:0 mapping:ffff8881f6c03000 index:0xffff8881ef61a700
flags: 0x2fffc0000000200(slab)
raw: 02fffc0000000200 ffffea0007ca4740 0000000500000005 ffff8881f6c03000
raw: ffff8881ef61a700 000000008010000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8881ef61ad00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8881ef61ad80: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
>ffff8881ef61ae00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8881ef61ae80: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
ffff8881ef61af00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb--- fs/configfs/dir.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
fs/configfs/dir.c +12 -5
@@ -1755,12 +1755,19 @@ int configfs_register_group(struct config_group *parent_group,inode_lock_nested (d_inode (parent),I_MUTEX_PARENT ); ret =create_default_group (parent_group, group); -if (!ret) { -spin_lock (&configfs_dirent_lock); -configfs_dir_set_ready (group->cg_item.ci_dentry->d_fsdata); -spin_unlock (&configfs_dirent_lock); - } +if (ret) + goto err_out; + +spin_lock (&configfs_dirent_lock); +configfs_dir_set_ready (group->cg_item.ci_dentry->d_fsdata); +spin_unlock (&configfs_dirent_lock); +inode_unlock (d_inode (parent)); +return 0 ; +err_out:inode_unlock (d_inode (parent)); +mutex_lock (&subsys->su_mutex); +unlink_group (group); +mutex_unlock (&subsys->su_mutex);return ret; }EXPORT_SYMBOL (configfs_register_group);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 58/155 uml: fix a boot splat wrt use of cpu_all_mask
In reply to Greg Kroah-Hartman[ Upstream commit 689a58605b63173acb0a8cf954af6a8f60440c93 ]
Memory: 509108K/542612K available (3835K kernel code, 919K rwdata, 1028K rodata, 129K init, 211K bss, 33504K reserved, 0K cma-reserved)NR_IRQS: 15
clocksource: timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns
------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/time/clockevents.c:458 clockevents_register_device+0x72/0x140 posix-timer cpumask == cpu_all_mask, using cpu_possible_mask instead Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.1.0-rc4-00048-ged79cc87302b #4 Stack: 604ebda0 603c5370 604ebe20 6046fd17 00000000 6006fcbb 604ebdb0 603c53b5 604ebe10 6003bfc4 604ebdd0 9000001ca Call Trace: [<6006fcbb>] ? printk+0x0/0x94 [<60083160>] ? clockevents_register_device+0x72/0x140 [<6001f16e>] show_stack+0x13b/0x155 [<603c5370>] ? dump_stack_print_info+0xe2/0xeb [<6006fcbb>] ? printk+0x0/0x94 [<603c53b5>] dump_stack+0x2a/0x2c [<6003bfc4>] __warn+0x10e/0x13e [<60070320>] ? vprintk_func+0xc8/0xcf [<60030fd6>] ? block_signals+0x0/0x16 [<6006fcbb>] ? printk+0x0/0x94 [<6003c08b>] warn_slowpath_fmt+0x97/0x99 [<600311a1>] ? set_signals+0x0/0x3f [<6003bff4>] ? warn_slowpath_fmt+0x0/0x99 [<600842cb>] ? tick_oneshot_mode_active+0x44/0x4f [<60030fd6>] ? block_signals+0x0/0x16 [<6006fcbb>] ? printk+0x0/0x94 [<6007d2d5>] ? __clocksource_select+0x20/0x1b1 [<60030fd6>] ? block_signals+0x0/0x16 [<6006fcbb>] ? printk+0x0/0x94 [<60083160>] clockevents_register_device+0x72/0x140 [<60031192>] ? get_signals+0x0/0xf [<60030fd6>] ? block_signals+0x0/0x16 [<6006fcbb>] ? printk+0x0/0x94 [<60002eec>] um_timer_setup+0xc8/0xca [<60001b59>] start_kernel+0x47f/0x57e [<600035bc>] start_kernel_proc+0x49/0x4d [<6006c483>] ? kmsg_dump_register+0x82/0x8a [<6001de62>] new_thread_handler+0x81/0xb2 [<60003571>] ? kmsg_dumper_stdout_init+0x1a/0x1c [<60020c75>] uml_finishsetup+0x54/0x59
random: get_random_bytes called from init_oops_id+0x27/0x34 with crng_init=0
---[ end trace 00173d0117a88acb ]---
Calibrating delay loop... 6941.90 BogoMIPS (lpj=34709504)
--- arch/um/kernel/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/um/kernel/time.c +1 -1
@@ -56,7 +56,7 @@ static int itimer_one_shot(struct clock_event_device *evt)static struct clock_event_device timer_clockevent = { .name ="posix-timer" , .rating =250 , - .cpumask = cpu_all_mask, + .cpumask = cpu_possible_mask, .features =CLOCK_EVT_FEAT_PERIODIC |CLOCK_EVT_FEAT_ONESHOT , .set_state_shutdown = itimer_shutdown,
Signature · 9 lines
2.20.1 _______________________________________________ linux-um mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-um
Greg Kroah-Hartman
maintainerPATCH 59/155 PCI: dwc: Free MSI in dw_pcie_host_init() error path
In reply to Greg Kroah-Hartman[ Upstream commit 9e2b5de5604a6ff2626c51e77014d92c9299722c ]
If we ever did MSI-related initializations, we need to call dw_pcie_free_msi() in the error code path.
Remove the IS_ENABLED(CONFIG_PCI_MSI) check for MSI init because pci_msi_enabled() already has a stub for !CONFIG_PCI_MSI.
--- drivers/pci/controller/dwc/pcie-designware-host.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/pci/controller/dwc/pcie-designware-host.c +6 -3
@@ -439,7 +439,7 @@ int dw_pcie_host_init(struct pcie_port *pp)if (ret) pci->num_viewport =2 ; -if (IS_ENABLED (CONFIG_PCI_MSI ) &&pci_msi_enabled ()) { +if (pci_msi_enabled ()) {/* * If a specific SoC driver needs to change the * default number of vectors, it needs to implement
@@ -477,7 +477,7 @@ int dw_pcie_host_init(struct pcie_port *pp)if (pp->ops->host_init) { ret = pp->ops->host_init (pp);if (ret) - goto error; + goto err_free_msi; } pp->root_bus_nr = pp->busn->start;
@@ -491,7 +491,7 @@ int dw_pcie_host_init(struct pcie_port *pp) ret =pci_scan_root_bus_bridge (bridge);if (ret) - goto error; + goto err_free_msi; bus = bridge->bus;
@@ -507,6 +507,9 @@ int dw_pcie_host_init(struct pcie_port *pp)pci_bus_add_devices (bus);return 0 ; +err_free_msi: +if (pci_msi_enabled () && !pp->ops->msi_host_init) +dw_pcie_free_msi (pp); error:pci_free_host_bridge (bridge);return ret;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 60/155 PCI: dwc: Free MSI IRQ page in dw_pcie_free_msi()
In reply to Greg Kroah-Hartman[ Upstream commit dc69a3d567941784c3d00e1d0834582b42b0b3e7 ]
To avoid a memory leak, free the page allocated for MSI IRQ in dw_pcie_free_msi().
--- drivers/pci/controller/dwc/pcie-designware-host.c | 12 ++++++++---- drivers/pci/controller/dwc/pcie-designware.h | 1 + 2 files changed, 9 insertions(+), 4 deletions(-)
drivers/pci/controller/dwc/pcie-designware-host.c +8 -4
@@ -303,20 +303,24 @@ void dw_pcie_free_msi(struct pcie_port *pp)irq_domain_remove (pp->msi_domain);irq_domain_remove (pp->irq_domain); + +if (pp->msi_page) +__free_page (pp->msi_page); }void dw_pcie_msi_init (struct pcie_port *pp) {struct dw_pcie *pci =to_dw_pcie_from_pp (pp);struct device *dev = pci->dev; -struct page *page;u64 msi_target; - page =alloc_page (GFP_KERNEL ); - pp->msi_data =dma_map_page (dev, page,0 ,PAGE_SIZE ,DMA_FROM_DEVICE ); + pp->msi_page =alloc_page (GFP_KERNEL ); + pp->msi_data =dma_map_page (dev, pp->msi_page,0 ,PAGE_SIZE , +DMA_FROM_DEVICE );if (dma_mapping_error (dev, pp->msi_data)) {dev_err (dev,"Failed to map MSI data\n" ); -__free_page (page); +__free_page (pp->msi_page); + pp->msi_page =NULL ;return ; } msi_target = (u64 )pp->msi_data;
drivers/pci/controller/dwc/pcie-designware.h +1 -0
@@ -179,6 +179,7 @@ struct pcie_port {struct irq_domain *irq_domain;struct irq_domain *msi_domain;dma_addr_t msi_data; +struct page *msi_page;u32 num_vectors;u32 irq_mask[MAX_MSI_CTRLS ];raw_spinlock_t lock;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 61/155 fbcon: Dont reset logo_shown when logo is currently shown
In reply to Greg Kroah-Hartman[ Upstream commit 3c5a1b111373e669c8220803464c3a508a87e254 ]
When the logo is currently drawn on a virtual console, and the console loglevel is reduced to quiet, logo_shown must be left alone, so that it the scrolling region on that virtual console is properly reset.
--- drivers/video/fbdev/core/fbcon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/fbdev/core/fbcon.c +1 -1
@@ -1069,7 +1069,7 @@ static void fbcon_init(struct vc_data *vc, int init) cap = info->flags; -if (console_loglevel <=CONSOLE_LOGLEVEL_QUIET ) +if (logo_shown <0 && console_loglevel <=CONSOLE_LOGLEVEL_QUIET ) logo_shown =FBCON_LOGO_DONTSHOW ; if (vc != svc || logo_shown == FBCON_LOGO_DONTSHOW ||
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 62/155 ovl: do not generate duplicate fsnotify events for "fake" path
In reply to Greg Kroah-Hartman[ Upstream commit d989903058a83e8536cc7aadf9256a47d5c173fe ]
Overlayfs "fake" path is used for stacked file operations on underlying files. Operations on files with "fake" path must not generate fsnotify events with path data, because those events have already been generated at overlayfs layer and because the reported event->fd for fanotify marks on underlying inode/filesystem will have the wrong path (the overlayfs path).
--- fs/overlayfs/file.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
fs/overlayfs/file.c +4 -3
@@ -29,10 +29,11 @@ static struct file *ovl_open_realfile(const struct file *file,struct inode *inode =file_inode (file);struct file *realfile;const struct cred *old_cred; +int flags = file->f_flags |O_NOATIME |FMODE_NONOTIFY ; old_cred =ovl_override_creds (inode->i_sb); - realfile =open_with_fake_path (&file->f_path, file->f_flags |O_NOATIME , - realinode,current_cred ()); + realfile =open_with_fake_path (&file->f_path, flags, realinode, +current_cred ());revert_creds (old_cred); pr_debug("open(%p[%pD2/%c], 0%o) -> (%p, 0%o)\n",
@@ -50,7 +51,7 @@ static int ovl_change_flags(struct file *file, unsigned int flags)int err;/* No atime modificaton on underlying */ - flags |=O_NOATIME ; + flags |=O_NOATIME |FMODE_NONOTIFY ;/* If some flag changed that cannot be changed then something's amiss */ if (WARN_ON ((file->f_flags ^ flags) & ~OVL_SETFL_MASK ))
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 63/155 mmc: mmci: Prevent polling for busy detection in IRQ context
In reply to Greg Kroah-Hartman[ Upstream commit 8520ce1e17799b220ff421d4f39438c9c572ade3 ]
The IRQ handler, mmci_irq(), loops until all status bits have been cleared. However, the status bit signaling busy in variant->busy_detect_flag, may be set even if busy detection isn't monitored for the current request.
This may be the case for the CMD11 when switching the I/O voltage, which leads to that mmci_irq() busy loops in IRQ context. Fix this problem, by clearing the status bit for busy, before continuing to validate the condition for the loop. This is safe, because the busy status detection has already been taken care of by mmci_cmd_irq().
--- drivers/mmc/host/mmci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/mmc/host/mmci.c +3 -2
@@ -1550,9 +1550,10 @@ static irqreturn_t mmci_irq(int irq, void *dev_id) }/* -* Don't poll for busy completion in irq context. +* Busy detection has been handled by mmci_cmd_irq() above. +* Clear the status bit to prevent polling in IRQ context. */ -if (host->variant->busy_detect && host->busy_status) +if (host->variant->busy_detect_flag) status &= ~host->variant->busy_detect_flag; ret =1 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 64/155 netfilter: nf_flow_table: fix missing error check for rhashtable_insert_fast
In reply to Greg Kroah-Hartman[ Upstream commit 43c8f131184faf20c07221f3e09724611c6525d8 ]
rhashtable_insert_fast() may return an error value when memory allocation fails, but flow_offload_add() does not check for errors. This patch just adds missing error checking.
--- net/netfilter/nf_flow_table_core.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-)
net/netfilter/nf_flow_table_core.c +18 -7
@@ -185,14 +185,25 @@ static const struct rhashtable_params nf_flow_offload_rhash_params = {int flow_offload_add (struct nf_flowtable *flow_table,struct flow_offload *flow) { - flow->timeout = (u32 )jiffies; +int err; -rhashtable_insert_fast (&flow_table->rhashtable, - &flow->tuplehash[FLOW_OFFLOAD_DIR_ORIGINAL ].node, - nf_flow_offload_rhash_params); -rhashtable_insert_fast (&flow_table->rhashtable, - &flow->tuplehash[FLOW_OFFLOAD_DIR_REPLY ].node, - nf_flow_offload_rhash_params); + err =rhashtable_insert_fast (&flow_table->rhashtable, + &flow->tuplehash[0 ].node, + nf_flow_offload_rhash_params); +if (err <0 ) +return err; + + err =rhashtable_insert_fast (&flow_table->rhashtable, + &flow->tuplehash[1 ].node, + nf_flow_offload_rhash_params); +if (err <0 ) { +rhashtable_remove_fast (&flow_table->rhashtable, + &flow->tuplehash[0 ].node, + nf_flow_offload_rhash_params); +return err; + } + + flow->timeout = (u32 )jiffies;return 0 ; }EXPORT_SYMBOL_GPL (flow_offload_add);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 65/155 netfilter: nf_conntrack_h323: restore boundary check correctness
In reply to Greg Kroah-Hartman[ Upstream commit f5e85ce8e733c2547827f6268136b70b802eabdb ]
Since commit bc7d811ace4a ("netfilter: nf_ct_h323: Convert CHECK_BOUND macro to function"), NAT traversal for H.323 doesn't work, failing to parse H323-UserInformation. nf_h323_error_boundary() compares contents of the bitstring, not the addresses, preventing valid H.323 packets from being conntrack'd.
This looks like an oversight from when CHECK_BOUND macro was converted to a function.
To fix it, stop dereferencing bs->cur and bs->end.
--- net/netfilter/nf_conntrack_h323_asn1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/nf_conntrack_h323_asn1.c +1 -1
@@ -172,7 +172,7 @@ static int nf_h323_error_boundary(struct bitstr *bs, size_t bytes, size_t bits)if (bits %BITS_PER_BYTE >0 ) bytes++; -if (*bs->cur + bytes > *bs->end) +if (bs->cur + bytes > bs->end)return 1 ;return 0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 66/155 mips: Make sure dt memory regions are valid
In reply to Greg Kroah-Hartman[ Upstream commit 93fa5b280761a4dbb14c5330f260380385ab2b49 ]
There are situations when memory regions coming from dts may be too big for the platform physical address space. This especially concerns XPA-capable systems. Bootloader may determine more than 4GB memory available and pass it to the kernel over dts memory node, while kernel is built without XPA/64BIT support. In this case the region may either simply be truncated by add_memory_region() method or by u64->phys_addr_t type casting. But in worst case the method can even drop the memory region if it exceeds PHYS_ADDR_MAX size. So lets make sure the retrieved from dts memory regions are valid, and if some of them aren't, just manually truncate them with a warning printed out.
--- arch/mips/kernel/prom.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)
arch/mips/kernel/prom.c +13 -1
@@ -41,7 +41,19 @@ char *mips_get_machine_name(void)#ifdef CONFIG_USE_OF void __init early_init_dt_add_memory_arch (u64 base,u64 size) { -return add_memory_region (base, size,BOOT_MEM_RAM ); +if (base >=PHYS_ADDR_MAX ) { +pr_warn ("Trying to add an invalid memory region, skipped\n" ); +return ; + } + +/* Truncate the passed memory region instead of type casting */ +if (base + size -1 >=PHYS_ADDR_MAX || base + size < base) { +pr_warn ("Truncate memory region %llx @ %llx to size %llx\n" , + size, base,PHYS_ADDR_MAX - base); + size =PHYS_ADDR_MAX - base; + } + +add_memory_region (base, size,BOOT_MEM_RAM ); } int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 67/155 netfilter: nf_tables: fix base chain stat rcu_dereference usage
In reply to Greg Kroah-Hartman[ Upstream commit edbd82c5fba009f68d20b5db585be1e667c605f6 ]
Following splat gets triggered when nfnetlink monitor is running while xtables-nft selftests are running:
net/netfilter/nf_tables_api.c:1272 suspicious rcu_dereference_check() usage! other info that might help us debug this:
1 lock held by xtables-nft-mul/27006:
#0: 00000000e0f85be9 (&net->nft.commit_mutex){+.+.}, at: nf_tables_valid_genid+0x1a/0x50
Call Trace: nf_tables_fill_chain_info.isra.45+0x6cc/0x6e0 nf_tables_chain_notify+0xf8/0x1a0 nf_tables_commit+0x165c/0x1740
nf_tables_fill_chain_info() can be called both from dumps (rcu read locked) or from the transaction path if a userspace process subscribed to nftables notifications.
In the 'table dump' case, rcu_access_pointer() cannot be used: We do not hold transaction mutex so the pointer can be NULLed right after the check. Just unconditionally fetch the value, then have the helper return immediately if its NULL.
In the notification case we don't hold the rcu read lock, but updates are prevented due to transaction mutex. Use rcu_dereference_check() to make lockdep aware of this.
--- net/netfilter/nf_tables_api.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
net/netfilter/nf_tables_api.c +7 -2
@@ -1190,6 +1190,9 @@ static int nft_dump_stats(struct sk_buff *skb, struct nft_stats __percpu *stats)u64 pkts, bytes;int cpu; +if (!stats) +return 0 ; +memset (&total,0 ,sizeof (total));for_each_possible_cpu (cpu) { cpu_stats =per_cpu_ptr (stats, cpu);
@@ -1247,6 +1250,7 @@ static int nf_tables_fill_chain_info(struct sk_buff *skb, struct net *net,if (nft_is_base_chain (chain)) {const struct nft_base_chain *basechain =nft_base_chain (chain);const struct nf_hook_ops *ops = &basechain->ops; +struct nft_stats __percpu *stats;struct nlattr *nest; nest =nla_nest_start (skb,NFTA_CHAIN_HOOK );
@@ -1268,8 +1272,9 @@ static int nf_tables_fill_chain_info(struct sk_buff *skb, struct net *net,if (nla_put_string (skb,NFTA_CHAIN_TYPE , basechain->type->name)) goto nla_put_failure; -if (rcu_access_pointer (basechain->stats) && -nft_dump_stats (skb,rcu_dereference (basechain->stats))) + stats =rcu_dereference_check (basechain->stats, +lockdep_commit_lock_is_held (net)); +if (nft_dump_stats (skb, stats)) goto nla_put_failure; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 68/155 watchdog: imx2_wdt: Fix set_timeout for big timeout values
In reply to Greg Kroah-Hartman[ Upstream commit b07e228eee69601addba98b47b1a3850569e5013 ]
The documentated behavior is: if max_hw_heartbeat_ms is implemented, the minimum of the set_timeout argument and max_hw_heartbeat_ms should be used. This patch implements this behavior.
Previously only the first 7bits were used and the input argument was returned.
--- drivers/watchdog/imx2_wdt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/watchdog/imx2_wdt.c +3 -1
@@ -178,8 +178,10 @@ static void __imx2_wdt_set_timeout(struct watchdog_device *wdog,static int imx2_wdt_set_timeout (struct watchdog_device *wdog,unsigned int new_timeout) { -__imx2_wdt_set_timeout (wdog, new_timeout); +unsigned int actual; + actual =min (new_timeout, wdog->max_hw_heartbeat_ms *1000 ); +__imx2_wdt_set_timeout (wdog, actual); wdog->timeout = new_timeout;return 0 ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 69/155 watchdog: fix compile time error of pretimeout governors
In reply to Greg Kroah-Hartman[ Upstream commit a223770bfa7b6647f3a70983257bd89f9cafce46 ]
CONFIG_WATCHDOG_PRETIMEOUT_GOV build symbol adds watchdog_pretimeout.o object to watchdog.o, the latter is compiled only if CONFIG_WATCHDOG_CORE is selected, so it rightfully makes sense to add it as a dependency.
The change fixes the next compilation errors, if CONFIG_WATCHDOG_CORE=n and CONFIG_WATCHDOG_PRETIMEOUT_GOV=y are selected:
drivers/watchdog/pretimeout_noop.o: In function `watchdog_gov_noop_register':
drivers/watchdog/pretimeout_noop.c:35: undefined reference to watchdog_register_governor' drivers/watchdog/pretimeout_noop.o: In function watchdog_gov_noop_unregister':
drivers/watchdog/pretimeout_noop.c:40: undefined reference to `watchdog_unregister_governor'
drivers/watchdog/pretimeout_panic.o: In function `watchdog_gov_panic_register':
drivers/watchdog/pretimeout_panic.c:35: undefined reference to watchdog_register_governor' drivers/watchdog/pretimeout_panic.o: In function watchdog_gov_panic_unregister':
drivers/watchdog/pretimeout_panic.c:40: undefined reference to `watchdog_unregister_governor'
--- drivers/watchdog/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/watchdog/Kconfig +1 -0
@@ -2028,6 +2028,7 @@ comment "Watchdog Pretimeout Governors" config WATCHDOG_PRETIMEOUT_GOV bool "Enable watchdog pretimeout governors" + depends on WATCHDOG_CORE help The option allows to select watchdog pretimeout governors.
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 70/155 blk-mq: move cancel of requeue_work into blk_mq_release
In reply to Greg Kroah-Hartman[ Upstream commit fbc2a15e3433058582e5635aabe48a3011a644a8 ]
With holding queue's kobject refcount, it is safe for driver to schedule requeue. However, blk_mq_kick_requeue_list() may be called after blk_sync_queue() is done because of concurrent requeue activities, then requeue work may not be completed when freeing queue, and kernel oops is triggered.
So moving the cancel of requeue_work into blk_mq_release() for avoiding race between requeue and freeing queue.
--- block/blk-core.c | 1 - block/blk-mq.c | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-)
block/blk-core.c +0 -1
@@ -237,7 +237,6 @@ void blk_sync_queue(struct request_queue *q)struct blk_mq_hw_ctx *hctx;int i; -cancel_delayed_work_sync (&q->requeue_work);queue_for_each_hw_ctx (q, hctx, i)cancel_delayed_work_sync (&hctx->run_work); }
block/blk-mq.c +2 -0
@@ -2666,6 +2666,8 @@ void blk_mq_release(struct request_queue *q)struct blk_mq_hw_ctx *hctx;unsigned int i; +cancel_delayed_work_sync (&q->requeue_work); +/* hctx kobj stays in hctx */ queue_for_each_hw_ctx (q, hctx, i) {if (!hctx)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 71/155 iommu/vt-d: Set intel_iommu_gfx_mapped correctly
In reply to Greg Kroah-Hartman[ Upstream commit cf1ec4539a50bdfe688caad4615ca47646884316 ]
The intel_iommu_gfx_mapped flag is exported by the Intel IOMMU driver to indicate whether an IOMMU is used for the graphic device. In a virtualized IOMMU environment (e.g. QEMU), an include-all IOMMU is used for graphic device. This flag is found to be clear even the IOMMU is used.
--- drivers/iommu/intel-iommu.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/iommu/intel-iommu.c +4 -3
@@ -4055,9 +4055,7 @@ static void __init init_no_remapping_devices(void)/* This IOMMU has *only* gfx devices. Either bypass it or set the gfx_mapped flag, as appropriate */ -if (dmar_map_gfx) { - intel_iommu_gfx_mapped =1 ; - }else { +if (!dmar_map_gfx) { drhd->ignored =1 ;for_each_active_dev_scope (drhd->devices, drhd->devices_cnt, i, dev)
@@ -4896,6 +4894,9 @@ int __init intel_iommu_init(void) goto out_free_reserved_range; } +if (dmar_map_gfx) + intel_iommu_gfx_mapped =1 ; +init_no_remapping_devices (); ret =init_dmars ();
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 72/155 vfio-pci/nvlink2: Fix potential VMA leak
In reply to Greg Kroah-Hartman[ Upstream commit 2c85f2bd519457073444ec28bbb4743a4e4237a7 ]
If vfio_pci_register_dev_region() fails then we should rollback previous changes, ie. unmap the ATSD registers.
--- drivers/vfio/pci/vfio_pci_nvlink2.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/vfio/pci/vfio_pci_nvlink2.c +2 -0
@@ -472,6 +472,8 @@ int vfio_pci_ibm_npu2_init(struct vfio_pci_device *vdev)return 0 ; free_exit: +if (data->base) +memunmap (data->base);kfree (data);return ret;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 73/155 misc: pci_endpoint_test: Fix test_reg_bar to be updated in pci_endpoint_test
In reply to Greg Kroah-Hartman[ Upstream commit 8f220664570e755946db1282f48e07f26e1f2cb4 ]
commit 834b90519925 ("misc: pci_endpoint_test: Add support for PCI_ENDPOINT_TEST regs to be mapped to any BAR") while adding test_reg_bar in order to map PCI_ENDPOINT_TEST regs to be mapped to any BAR failed to update test_reg_bar in pci_endpoint_test, resulting in test_reg_bar having invalid value when used outside probe.
Fix it.
--- drivers/misc/pci_endpoint_test.c | 1 + 1 file changed, 1 insertion(+)
drivers/misc/pci_endpoint_test.c +1 -0
@@ -662,6 +662,7 @@ static int pci_endpoint_test_probe(struct pci_dev *pdev, data = (struct pci_endpoint_test_data *)ent->driver_data;if (data) { test_reg_bar = data->test_reg_bar; + test->test_reg_bar = test_reg_bar; test->alignment = data->alignment; irq_type = data->irq_type; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 74/155 PCI: designware-ep: Use aligned ATU window for raising MSI interrupts
In reply to Greg Kroah-Hartman[ Upstream commit 6b7330303a8186fb211357e6d379237fe9d2ece1 ]
Certain platforms like K2G reguires the outbound ATU window to be aligned. The alignment size is already present in mem->page_size. Use the alignment size present in mem->page_size to configure an aligned ATU window. In order to raise an interrupt, CPU has to write to address offset from the start of the window unlike before where writes were always to the beginning of the ATU window.
--- drivers/pci/controller/dwc/pcie-designware-ep.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/pci/controller/dwc/pcie-designware-ep.c +5 -2
@@ -397,6 +397,7 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no, {struct dw_pcie *pci =to_dw_pcie_from_ep (ep);struct pci_epc *epc = ep->epc; +unsigned int aligned_offset;u16 msg_ctrl, msg_data;u32 msg_addr_lower, msg_addr_upper, reg;u64 msg_addr;
@@ -422,13 +423,15 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no, reg = ep->msi_cap +PCI_MSI_DATA_32 ; msg_data =dw_pcie_readw_dbi (pci, reg); } - msg_addr = ((u64 ) msg_addr_upper) <<32 | msg_addr_lower; + aligned_offset = msg_addr_lower & (epc->mem->page_size -1 ); + msg_addr = ((u64 )msg_addr_upper) <<32 | + (msg_addr_lower & ~aligned_offset); ret =dw_pcie_ep_map_addr (epc, func_no, ep->msi_mem_phys, msg_addr, epc->mem->page_size);if (ret)return ret; -writel (msg_data | (interrupt_num -1 ), ep->msi_mem); +writel (msg_data | (interrupt_num -1 ), ep->msi_mem + aligned_offset);dw_pcie_ep_unmap_addr (epc, func_no, ep->msi_mem_phys);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 75/155 nvme-pci: unquiesce admin queue on shutdown
In reply to Greg Kroah-Hartman[ Upstream commit c8e9e9b7646ebe1c5066ddc420d7630876277eb4 ]
Just like IO queues, the admin queue also will not be restarted after a controller shutdown. Unquiesce this queue so that we do not block request dispatch on a permanently disabled controller.
--- drivers/nvme/host/pci.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/nvme/host/pci.c +4 -1
@@ -2438,8 +2438,11 @@ static void nvme_dev_disable(struct nvme_dev *dev, bool shutdown)* must flush all entered requests to their failed completion to avoid * deadlocking blk-mq hot-cpu notifier. */ -if (shutdown) +if (shutdown) {nvme_start_queues (&dev->ctrl); +if (dev->ctrl.admin_q && !blk_queue_dying (dev->ctrl.admin_q)) +blk_mq_unquiesce_queue (dev->ctrl.admin_q); + }mutex_unlock (&dev->shutdown_lock); }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 76/155 nvme-pci: shutdown on timeout during deletion
In reply to Greg Kroah-Hartman[ Upstream commit 9dc1a38ef1925d23c2933c5867df816386d92ff8 ]
We do not restart a controller in a deleting state for timeout errors. When in this state, unblock potential request dispatchers with failed completions by shutting down the controller on timeout detection.
--- drivers/nvme/host/pci.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/nvme/host/pci.c +4 -1
@@ -1271,6 +1271,7 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)struct nvme_dev *dev = nvmeq->dev;struct request *abort_req;struct nvme_command cmd; +bool shutdown = false;u32 csts =readl (dev->bar +NVME_REG_CSTS );/* If PCI error recovery process is happening, we cannot reset or
@@ -1307,12 +1308,14 @@ static enum blk_eh_timer_return nvme_timeout(struct request *req, bool reserved)* shutdown, so we return BLK_EH_DONE. */ switch (dev->ctrl.state) { +case NVME_CTRL_DELETING : + shutdown = true;case NVME_CTRL_CONNECTING :case NVME_CTRL_RESETTING :dev_warn_ratelimited (dev->ctrl.device,"I/O %d QID %d timeout, disable controller\n" , req->tag, nvmeq->qid); -nvme_dev_disable (dev, false); +nvme_dev_disable (dev, shutdown);nvme_req (req)->flags |=NVME_REQ_CANCELLED ;return BLK_EH_DONE ;default :
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 77/155 netfilter: nf_flow_table: check ttl value in flow offload data path
In reply to Greg Kroah-Hartman[ Upstream commit 33cc3c0cfa64c86b6c4bbee86997aea638534931 ]
nf_flow_offload_ip_hook() and nf_flow_offload_ipv6_hook() do not check ttl value. So, ttl value overflow may occur.
--- net/netfilter/nf_flow_table_ip.c | 6 ++++++ 1 file changed, 6 insertions(+)
net/netfilter/nf_flow_table_ip.c +6 -0
@@ -181,6 +181,9 @@ static int nf_flow_tuple_ip(struct sk_buff *skb, const struct net_device *dev, iph->protocol != IPPROTO_UDP)return -1 ; +if (iph->ttl <=1 ) +return -1 ; + thoff = iph->ihl *4 ;if (!pskb_may_pull (skb, thoff +sizeof (*ports)))return -1 ;
@@ -411,6 +414,9 @@ static int nf_flow_tuple_ipv6(struct sk_buff *skb, const struct net_device *dev, ip6h->nexthdr != IPPROTO_UDP)return -1 ; +if (ip6h->hop_limit <=1 ) +return -1 ; + thoff =sizeof (*ip6h);if (!pskb_may_pull (skb, thoff +sizeof (*ports)))return -1 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 78/155 netfilter: nf_flow_table: fix netdev refcnt leak
In reply to Greg Kroah-Hartman[ Upstream commit 26a302afbe328ecb7507cae2035d938e6635131b ]
flow_offload_alloc() calls nf_route() to get a dst_entry. Internally, nf_route() calls ip_route_output_key() that allocates a dst_entry and holds it. So, a dst_entry should be released by dst_release() if nf_route() is successful.
Otherwise, netns exit routine cannot be finished and the following message is printed:
[ 257.490952] unregister_netdevice: waiting for lo to become free. Usage count = 1
--- net/netfilter/nft_flow_offload.c | 1 + 1 file changed, 1 insertion(+)
net/netfilter/nft_flow_offload.c +1 -0
@@ -113,6 +113,7 @@ static void nft_flow_offload_eval(const struct nft_expr *expr,if (ret <0 ) goto err_flow_add; +dst_release (route.tuple[!dir].dst);return ; err_flow_add:
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 79/155 ALSA: hda - Register irq handler after the chip initialization
In reply to Greg Kroah-Hartman[ Upstream commit f495222e28275222ab6fd93813bd3d462e16d340 ]
Currently the IRQ handler in HD-audio controller driver is registered before the chip initialization. That is, we have some window opened between the azx_acquire_irq() call and the CORB/RIRB setup. If an interrupt is triggered in this small window, the IRQ handler may access to the uninitialized RIRB buffer, which leads to a NULL dereference Oops.
This is usually no big problem since most of Intel chips do register the IRQ via MSI, and we've already fixed the order of the IRQ enablement and the CORB/RIRB setup in the former commit b61749a89f82 ("sound: enable interrupt after dma buffer initialization"), hence the IRQ won't be triggered in that room. However, some platforms use a shared IRQ, and this may allow the IRQ trigger by another source.
Another possibility is the kdump environment: a stale interrupt might be present in there, the IRQ handler can be falsely triggered as well.
For covering this small race, let's move the azx_acquire_irq() call after hda_intel_init_chip() call. Although this is a bit radical change, it can cover more widely than checking the CORB/RIRB setup locally in the callee side.
--- sound/pci/hda/hda_intel.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
sound/pci/hda/hda_intel.c +3 -3
@@ -1788,9 +1788,6 @@ static int azx_first_init(struct azx *chip) chip->msi =0 ; } -if (azx_acquire_irq (chip,0 ) <0 ) -return -EBUSY ; -pci_set_master (pci);synchronize_irq (bus->irq);
@@ -1904,6 +1901,9 @@ static int azx_first_init(struct azx *chip)return -ENODEV ; } +if (azx_acquire_irq (chip,0 ) <0 ) +return -EBUSY ; +strcpy (card->driver,"HDA-Intel" );strlcpy (card->shortname, driver_short_names[chip->driver_type],sizeof (card->shortname));
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 80/155 powerpc/pseries: Track LMB nid instead of using device tree
In reply to Greg Kroah-Hartman[ Upstream commit b2d3b5ee66f2a04a918cc043cec0c9ed3de58f40 ]
When removing memory we need to remove the memory from the node it was added to instead of looking up the node it should be in in the device tree.
During testing we have seen scenarios where the affinity for a LMB changes due to a partition migration or PRRN event. In these cases the node the LMB exists in may not match the node the device tree indicates it belongs in. This can lead to a system crash when trying to DLPAR remove the LMB after a migration or PRRN event. The current code looks up the node in the device tree to remove the LMB from, the crash occurs when we try to offline this node and it does not have any data, i.e. node_data[nid] == NULL.
36:mon> e
cpu 0x36: Vector: 300 (Data Access) at [c0000001828b7810]
pc: c00000000036d08c: try_offline_node+0x2c/0x1b0
lr: c0000000003a14ec: remove_memory+0xbc/0x110
sp: c0000001828b7a90
msr: 800000000280b033
dar: 9a28
dsisr: 40000000
current = 0xc0000006329c4c80
paca = 0xc000000007a55200 softe: 0 irq_happened: 0x01
pid = 76926, comm = kworker/u320:336:mon> t
[link register ] c0000000003a14ec remove_memory+0xbc/0x110
[c0000001828b7a90] c00000000006a1cc arch_remove_memory+0x9c/0xd0 (unreliable) [c0000001828b7ad0] c0000000003a14e0 remove_memory+0xb0/0x110 [c0000001828b7b20] c0000000000c7db4 dlpar_remove_lmb+0x94/0x160 [c0000001828b7b60] c0000000000c8ef8 dlpar_memory+0x7e8/0xd10 [c0000001828b7bf0] c0000000000bf828 handle_dlpar_errorlog+0xf8/0x160 [c0000001828b7c60] c0000000000bf8cc pseries_hp_work_fn+0x3c/0xa0 [c0000001828b7c90] c000000000128cd8 process_one_work+0x298/0x5a0 [c0000001828b7d20] c000000000129068 worker_thread+0x88/0x620 [c0000001828b7dc0] c00000000013223c kthread+0x1ac/0x1c0 [c0000001828b7e30] c00000000000b45c ret_from_kernel_thread+0x5c/0x80
To resolve this we need to track the node a LMB belongs to when it is added to the system so we can remove it from that node instead of the node that the device tree indicates it should belong to.
--- arch/powerpc/include/asm/drmem.h | 21 +++++++++++++++++++ arch/powerpc/mm/drmem.c | 6 +++++- .../platforms/pseries/hotplug-memory.c | 17 +++++++-------- 3 files changed, 34 insertions(+), 10 deletions(-)
arch/powerpc/include/asm/drmem.h +21 -0
@@ -17,6 +17,9 @@ struct drmem_lmb {u32 drc_index;u32 aa_index;u32 flags; +#ifdef CONFIG_MEMORY_HOTPLUG +int nid; +#endif };struct drmem_lmb_info {
@@ -104,4 +107,22 @@ static inline void invalidate_lmb_associativity_index(struct drmem_lmb *lmb) lmb->aa_index = 0xffffffff; } +#ifdef CONFIG_MEMORY_HOTPLUG +static inline void lmb_set_nid (struct drmem_lmb *lmb) +{ + lmb->nid =memory_add_physaddr_to_nid (lmb->base_addr); +} +static inline void lmb_clear_nid (struct drmem_lmb *lmb) +{ + lmb->nid =-1 ; +} +#else +static inline void lmb_set_nid (struct drmem_lmb *lmb) +{ +} +static inline void lmb_clear_nid (struct drmem_lmb *lmb) +{ +} +#endif +#endif /* _ASM_POWERPC_LMB_H */
arch/powerpc/mm/drmem.c +5 -1
@@ -366,8 +366,10 @@ static void __init init_drmem_v1_lmbs(const __be32 *prop)if (!drmem_info->lmbs)return ; -for_each_drmem_lmb (lmb) +for_each_drmem_lmb (lmb) {read_drconf_v1_cell (lmb, &prop); +lmb_set_nid (lmb); + } }static void __init init_drmem_v2_lmbs (const __be32 *prop)
@@ -412,6 +414,8 @@ static void __init init_drmem_v2_lmbs(const __be32 *prop) lmb->aa_index = dr_cell.aa_index; lmb->flags = dr_cell.flags; + +lmb_set_nid (lmb); } } }
arch/powerpc/platforms/pseries/hotplug-memory.c +8 -9
@@ -379,7 +379,7 @@ static int dlpar_add_lmb(struct drmem_lmb *);static int dlpar_remove_lmb (struct drmem_lmb *lmb) {unsigned long block_sz; -int nid, rc; +int rc;if (!lmb_is_removable (lmb))return -EINVAL ;
@@ -389,14 +389,14 @@ static int dlpar_remove_lmb(struct drmem_lmb *lmb)return rc; block_sz =pseries_memory_block_size (); - nid =memory_add_physaddr_to_nid (lmb->base_addr); -__remove_memory (nid, lmb->base_addr, block_sz); +__remove_memory (lmb->nid, lmb->base_addr, block_sz);/* Update memory regions for memory remove */ memblock_remove (lmb->base_addr, block_sz);invalidate_lmb_associativity_index (lmb); +lmb_clear_nid (lmb); lmb->flags &= ~DRCONF_MEM_ASSIGNED ;return 0 ;
@@ -653,7 +653,7 @@ static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)static int dlpar_add_lmb (struct drmem_lmb *lmb) {unsigned long block_sz; -int nid, rc; +int rc;if (lmb->flags &DRCONF_MEM_ASSIGNED )return -EINVAL ;
@@ -664,13 +664,11 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)return rc; } +lmb_set_nid (lmb); block_sz =memory_block_size_bytes (); -/* Find the node id for this address */ - nid =memory_add_physaddr_to_nid (lmb->base_addr); -/* Add the memory */ - rc =__add_memory (nid, lmb->base_addr, block_sz); + rc =__add_memory (lmb->nid, lmb->base_addr, block_sz);if (rc) {invalidate_lmb_associativity_index (lmb);return rc;
@@ -678,8 +676,9 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb) rc =dlpar_online_lmb (lmb);if (rc) { -__remove_memory (nid, lmb->base_addr, block_sz); +__remove_memory (lmb->nid, lmb->base_addr, block_sz);invalidate_lmb_associativity_index (lmb); +lmb_clear_nid (lmb); }else { lmb->flags |=DRCONF_MEM_ASSIGNED ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 81/155 arm64: defconfig: Update UFSHCD for Hi3660 soc
In reply to Greg Kroah-Hartman[ Upstream commit 7b3320e6b1795d68b7e30eb3fad0860f2664aedd ]
Commit 7ee7ef24d02d ("scsi: arm64: defconfig: enable configs for Hisilicon ufs") set 'CONFIG_SCSI_UFS_HISI=y', but the configs it depends
on
(CONFIG_SCSI_HFSHCD_PLATFORM && CONFIG_SCSI_UFSHCD)
were left to being built as modules.
Commit 1f4fa50dd48f ("arm64: defconfig: Regenerate for v4.20") "fixed" that by reverting to 'CONFIG_SCSI_UFS_HISI=m'.
Thing is, if the rootfs is stored in the on-board flash (which is the "canonical" way of doing things), we either need these drivers to be built-in, or we need to fiddle with an initramfs to access that flash and eventually load the modules installed over there.
The former is the easiest, do that.
--- arch/arm64/configs/defconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/configs/defconfig +3 -3
@@ -222,10 +222,10 @@ CONFIG_BLK_DEV_SD=y CONFIG_SCSI_SAS_ATA=y CONFIG_SCSI_HISI_SAS=y CONFIG_SCSI_HISI_SAS_PCI=y -CONFIG_SCSI_UFSHCD=m -CONFIG_SCSI_UFSHCD_PLATFORM=m +CONFIG_SCSI_UFSHCD=y +CONFIG_SCSI_UFSHCD_PLATFORM=y CONFIG_SCSI_UFS_QCOM=m -CONFIG_SCSI_UFS_HISI=m +CONFIG_SCSI_UFS_HISI=y CONFIG_ATA=y CONFIG_SATA_AHCI=y CONFIG_SATA_AHCI_PLATFORM=y
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 82/155 iommu/vt-d: Dont request page request irq under dmar_global_lock
In reply to Greg Kroah-Hartman[ Upstream commit a7755c3cfa5df755e39447b08c28203e011fb98c ]
Requesting page reqest irq under dmar_global_lock could cause potential lock race condition (caught by lockdep).
[ 4.100055] ======================================================
[ 4.100063] WARNING: possible circular locking dependency detected
[ 4.100072] 5.1.0-rc4+ #2169 Not tainted
[ 4.100078] ------------------------------------------------------
[ 4.100086] swapper/0/1 is trying to acquire lock:
[ 4.100094] 000000007dcbe3c3 (dmar_lock){+.+.}, at: dmar_alloc_hwirq+0x35/0x140
[ 4.100112] but task is already holding lock:
[ 4.100120] 0000000060bbe946 (dmar_global_lock){++++}, at: intel_iommu_init+0x191/0x1438
[ 4.100136] which lock already depends on the new lock.
[ 4.100146] the existing dependency chain (in reverse order) is:
[ 4.100155]
-> #2 (dmar_global_lock){++++}:
[ 4.100169] down_read+0x44/0xa0
[ 4.100178] intel_irq_remapping_alloc+0xb2/0x7b0
[ 4.100186] mp_irqdomain_alloc+0x9e/0x2e0
[ 4.100195] __irq_domain_alloc_irqs+0x131/0x330
[ 4.100203] alloc_isa_irq_from_domain.isra.4+0x9a/0xd0
[ 4.100212] mp_map_pin_to_irq+0x244/0x310
[ 4.100221] setup_IO_APIC+0x757/0x7ed
[ 4.100229] x86_late_time_init+0x17/0x1c
[ 4.100238] start_kernel+0x425/0x4e3
[ 4.100247] secondary_startup_64+0xa4/0xb0
[ 4.100254]
-> #1 (irq_domain_mutex){+.+.}:
[ 4.100265] __mutex_lock+0x7f/0x9d0
[ 4.100273] __irq_domain_add+0x195/0x2b0
[ 4.100280] irq_domain_create_hierarchy+0x3d/0x40
[ 4.100289] msi_create_irq_domain+0x32/0x110
[ 4.100297] dmar_alloc_hwirq+0x111/0x140
[ 4.100305] dmar_set_interrupt.part.14+0x1a/0x70
[ 4.100314] enable_drhd_fault_handling+0x2c/0x6c
[ 4.100323] apic_bsp_setup+0x75/0x7a
[ 4.100330] x86_late_time_init+0x17/0x1c
[ 4.100338] start_kernel+0x425/0x4e3
[ 4.100346] secondary_startup_64+0xa4/0xb0
[ 4.100352]
-> #0 (dmar_lock){+.+.}:
[ 4.100364] lock_acquire+0xb4/0x1c0
[ 4.100372] __mutex_lock+0x7f/0x9d0
[ 4.100379] dmar_alloc_hwirq+0x35/0x140
[ 4.100389] intel_svm_enable_prq+0x61/0x180
[ 4.100397] intel_iommu_init+0x1128/0x1438
[ 4.100406] pci_iommu_init+0x16/0x3f
[ 4.100414] do_one_initcall+0x5d/0x2be
[ 4.100422] kernel_init_freeable+0x1f0/0x27c
[ 4.100431] kernel_init+0xa/0x110
[ 4.100438] ret_from_fork+0x3a/0x50
[ 4.100444]
other info that might help us debug this:[ 4.100454] Chain exists of:
dmar_lock --> irq_domain_mutex --> dmar_global_lock
[ 4.100469] Possible unsafe locking scenario:[ 4.100476] CPU0 CPU1
[ 4.100483] ---- ----
[ 4.100488] lock(dmar_global_lock);
[ 4.100495] lock(irq_domain_mutex);
[ 4.100503] lock(dmar_global_lock);
[ 4.100512] lock(dmar_lock);
[ 4.100518]
*** DEADLOCK ***--- drivers/iommu/intel-iommu.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/iommu/intel-iommu.c +6 -0
@@ -3496,7 +3496,13 @@ domains_done:#ifdef CONFIG_INTEL_IOMMU_SVM if (pasid_supported (iommu) &&ecap_prs (iommu->ecap)) { +/* +* Call dmar_alloc_hwirq() with dmar_global_lock held, +* could cause possible lock race condition. +*/ +up_write (&dmar_global_lock); ret =intel_svm_enable_prq (iommu); +down_write (&dmar_global_lock);if (ret) goto free_iommu; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 83/155 nvmem: core: fix read buffer in place
In reply to Greg Kroah-Hartman[ Upstream commit 2fe518fecb3a4727393be286db9804cd82ee2d91 ]
When the bit_offset in the cell is zero, the pointer to the msb will not be properly initialized (ie, will still be pointing to the first byte in the buffer).
This being the case, if there are bits to clear in the msb, those will be left untouched while the mask will incorrectly clear bit positions on the first byte.
This commit also makes sure that any byte unused in the cell is cleared.
--- drivers/nvmem/core.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)
drivers/nvmem/core.c +10 -5
@@ -1166,7 +1166,7 @@ EXPORT_SYMBOL_GPL(nvmem_cell_put);static void nvmem_shift_read_buffer_in_place (struct nvmem_cell *cell,void *buf) {u8 *p, *b; -int i, bit_offset = cell->bit_offset; +int i, extra, bit_offset = cell->bit_offset; p = b = buf;if (bit_offset) {
@@ -1181,11 +1181,16 @@ static void nvmem_shift_read_buffer_in_place(struct nvmem_cell *cell, void *buf) p = b; *b++ >>= bit_offset; } - -/* result fits in less bytes */ -if (cell->bytes !=DIV_ROUND_UP (cell->nbits,BITS_PER_BYTE )) - *p-- =0 ; + }else { +/* point to the msb */ + p += cell->bytes -1 ; } + +/* result fits in less bytes */ + extra = cell->bytes -DIV_ROUND_UP (cell->nbits,BITS_PER_BYTE ); +while (--extra >=0 ) + *p-- =0 ; +/* clear msb bits if any leftover in the last byte */ *p &=GENMASK ((cell->nbits%BITS_PER_BYTE ) -1 ,0 ); }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 84/155 nvmem: sunxi_sid: Support SID on A83T and H5
In reply to Greg Kroah-Hartman[ Upstream commit da75b8909756160b8e785104ba421a20b756c975 ]
The device tree binding already lists compatible strings for these two SoCs. They don't have the defect as seen on the H3, and the size and register layout is the same as the A64. Furthermore, the driver does not include nvmem cell definitions.
Add support for these two compatible strings, re-using the config for the A64.
--- drivers/nvmem/sunxi_sid.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/nvmem/sunxi_sid.c +2 -0
@@ -222,8 +222,10 @@ static const struct sunxi_sid_cfg sun50i_a64_cfg = {static const struct of_device_id sunxi_sid_of_match[] = { { .compatible ="allwinner,sun4i-a10-sid" , .data = &sun4i_a10_cfg }, { .compatible ="allwinner,sun7i-a20-sid" , .data = &sun7i_a20_cfg }, + { .compatible ="allwinner,sun8i-a83t-sid" , .data = &sun50i_a64_cfg }, { .compatible ="allwinner,sun8i-h3-sid" , .data = &sun8i_h3_cfg }, { .compatible ="allwinner,sun50i-a64-sid" , .data = &sun50i_a64_cfg }, + { .compatible ="allwinner,sun50i-h5-sid" , .data = &sun50i_a64_cfg }, {/* sentinel */ }, };MODULE_DEVICE_TABLE (of, sunxi_sid_of_match);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 85/155 fuse: retrieve: cap requested size to negotiated max_write
In reply to Greg Kroah-Hartman[ Upstream commit 7640682e67b33cab8628729afec8ca92b851394f ]
FUSE filesystem server and kernel client negotiate during initialization phase, what should be the maximum write size the client will ever issue. Correspondingly the filesystem server then queues sys_read calls to read requests with buffer capacity large enough to carry request header + that max_write bytes. A filesystem server is free to set its max_write in anywhere in the range between [1*page, fc->max_pages*page]. In particular go-fuse[2] sets max_write by default as 64K, wheres default fc->max_pages corresponds to 128K. Libfuse also allows users to configure max_write, but by default presets it to possible maximum.
If max_write is < fc->max_pages*page, and in NOTIFY_RETRIEVE handler we allow to retrieve more than max_write bytes, corresponding prepared NOTIFY_REPLY will be thrown away by fuse_dev_do_read, because the filesystem server, in full correspondence with server/client contract, will be only queuing sys_read with ~max_write buffer capacity, and fuse_dev_do_read throws away requests that cannot fit into server request buffer. In turn the filesystem server could get stuck waiting indefinitely for NOTIFY_REPLY since NOTIFY_RETRIEVE handler returned OK which is understood by clients as that NOTIFY_REPLY was queued and will be sent back.
Cap requested size to negotiate max_write to avoid the problem. This aligns with the way NOTIFY_RETRIEVE handler works, which already unconditionally caps requested retrieve size to fuse_conn->max_pages. This way it should not hurt NOTIFY_RETRIEVE semantic if we return less data than was originally requested.
Please see [1] for context where the problem of stuck filesystem was hit for real, how the situation was traced and for more involving patch that did not make it into the tree.
[1] https://marc.info/?l=linux-fsdevel&m=155057023600853&w=2
[2] https://github.com/hanwen/go-fuse
--- fs/fuse/dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/fuse/dev.c +1 -1
@@ -1749,7 +1749,7 @@ static int fuse_retrieve(struct fuse_con offset = outarg->offset & ~PAGE_MASK ; file_size =i_size_read (inode); - num = outarg->size; + num =min (outarg->size, fc->max_write);if (outarg->offset > file_size) num =0 ;else if (outarg->offset + num > file_size)
Greg Kroah-Hartman
maintainerPATCH 86/155 nfsd: allow fh_want_write to be called twice
In reply to Greg Kroah-Hartman[ Upstream commit 0b8f62625dc309651d0efcb6a6247c933acd8b45 ]
A fuzzer recently triggered lockdep warnings about potential sb_writers deadlocks caused by fh_want_write().
Looks like we aren't careful to pair each fh_want_write() with an fh_drop_write().
It's not normally a problem since fh_put() will call fh_drop_write() for us. And was OK for NFSv3 where we'd do one operation that might call fh_want_write(), and then put the filehandle.
But an NFSv4 protocol fuzzer can do weird things like call unlink twice in a compound, and then we get into trouble.
I'm a little worried about this approach of just leaving everything to fh_put(). But I think there are probably a lot of fh_want_write()/fh_drop_write() imbalances so for now I think we need it to be more forgiving.
--- fs/nfsd/vfs.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
fs/nfsd/vfs.h +4 -1
@@ -120,8 +120,11 @@ void nfsd_put_raparams(struct file *file, struct raparms *ra);static inline int fh_want_write (struct svc_fh *fh) { -int ret =mnt_want_write (fh->fh_export->ex_path.mnt); +int ret; +if (fh->fh_want_write) +return 0 ; + ret =mnt_want_write (fh->fh_export->ex_path.mnt);if (!ret) fh->fh_want_write = true;return ret;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 87/155 nfsd: avoid uninitialized variable warning
In reply to Greg Kroah-Hartman[ Upstream commit 0ab88ca4bcf18ba21058d8f19220f60afe0d34d8 ]
clang warns that 'contextlen' may be accessed without an initialization:
fs/nfsd/nfs4xdr.c:2911:9: error: variable 'contextlen' is uninitialized when used here [-Werror,-Wuninitialized]
contextlen);
^~~~~~~~~~
fs/nfsd/nfs4xdr.c:2424:16: note: initialize the variable 'contextlen' to silence this warning
int contextlen;
^
= 0Presumably this cannot happen, as FATTR4_WORD2_SECURITY_LABEL is set if CONFIG_NFSD_V4_SECURITY_LABEL is enabled. Adding another #ifdef like the other two in this function avoids the warning.
--- fs/nfsd/nfs4xdr.c | 4 ++++ 1 file changed, 4 insertions(+)
fs/nfsd/nfs4xdr.c +4 -0
@@ -2420,8 +2420,10 @@ nfsd4_encode_fattr(struct xdr_stream *xdr, struct svc_fh *fhp,__be32 status;int err;struct nfs4_acl *acl =NULL ; +#ifdef CONFIG_NFSD_V4_SECURITY_LABEL void *context =NULL ;int contextlen; +#endif bool contextsupport = false;struct nfsd4_compoundres *resp = rqstp->rq_resp;u32 minorversion = resp->cstate.minorversion;
@@ -2906,12 +2908,14 @@ out_acl: *p++ =cpu_to_be32 (NFS4_CHANGE_TYPE_IS_TIME_METADATA ); } +#ifdef CONFIG_NFSD_V4_SECURITY_LABEL if (bmval2 &FATTR4_WORD2_SECURITY_LABEL ) { status =nfsd4_encode_security_label (xdr, rqstp, context, contextlen);if (status) goto out; } +#endif attrlen =htonl (xdr->buf->len - attrlen_offset -4 );write_bytes_to_xdr_buf (xdr->buf, attrlen_offset, &attrlen,4 );
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 88/155 vfio: Fix WARNING "do not call blocking ops when !TASK_RUNNING"
In reply to Greg Kroah-Hartman[ Upstream commit 41be3e2618174fdf3361e49e64f2bf530f40c6b0 ]
vfio_dev_present() which is the condition to wait_event_interruptible_timeout(), will call vfio_group_get_device and try to acquire the mutex group->device_lock.
wait_event_interruptible_timeout() will set the state of the current task to TASK_INTERRUPTIBLE, before doing the condition check. This means that we will try to acquire the mutex while already in a sleeping state. The scheduler warns us by giving the following warning:
[ 4050.264464] ------------[ cut here ]------------ [ 4050.264508] do not call blocking ops when !TASK_RUNNING; state=1 set at [<00000000b33c00e2>] prepare_to_wait_event+0x14a/0x188 [ 4050.264529] WARNING: CPU: 12 PID: 35924 at kernel/sched/core.c:6112 __might_sleep+0x76/0x90
....
4050.264756] Call Trace:
[ 4050.264765] ([<000000000017bbaa>] __might_sleep+0x72/0x90)
[ 4050.264774] [<0000000000b97edc>] __mutex_lock+0x44/0x8c0
[ 4050.264782] [<0000000000b9878a>] mutex_lock_nested+0x32/0x40
[ 4050.264793] [<000003ff800d7abe>] vfio_group_get_device+0x36/0xa8 [vfio]
[ 4050.264803] [<000003ff800d87c0>] vfio_del_group_dev+0x238/0x378 [vfio]
[ 4050.264813] [<000003ff8015f67c>] mdev_remove+0x3c/0x68 [mdev]
[ 4050.264825] [<00000000008e01b0>] device_release_driver_internal+0x168/0x268
[ 4050.264834] [<00000000008de692>] bus_remove_device+0x162/0x190
[ 4050.264843] [<00000000008daf42>] device_del+0x1e2/0x368
[ 4050.264851] [<00000000008db12c>] device_unregister+0x64/0x88
[ 4050.264862] [<000003ff8015ed84>] mdev_device_remove+0xec/0x130 [mdev]
[ 4050.264872] [<000003ff8015f074>] remove_store+0x6c/0xa8 [mdev]
[ 4050.264881] [<000000000046f494>] kernfs_fop_write+0x14c/0x1f8
[ 4050.264890] [<00000000003c1530>] __vfs_write+0x38/0x1a8
[ 4050.264899] [<00000000003c187c>] vfs_write+0xb4/0x198
[ 4050.264908] [<00000000003c1af2>] ksys_write+0x5a/0xb0
[ 4050.264916] [<0000000000b9e270>] system_call+0xdc/0x2d8
[ 4050.264925] 4 locks held by sh/35924:
[ 4050.264933] #0: 000000001ef90325 (sb_writers#4){.+.+}, at: vfs_write+0x9e/0x198
[ 4050.264948] #1: 000000005c1ab0b3 (&of->mutex){+.+.}, at: kernfs_fop_write+0x1cc/0x1f8
[ 4050.264963] #2: 0000000034831ab8 (kn->count#297){++++}, at: kernfs_remove_self+0x12e/0x150
[ 4050.264979] #3: 00000000e152484f (&dev->mutex){....}, at: device_release_driver_internal+0x5c/0x268
[ 4050.264993] Last Breaking-Event-Address:
[ 4050.265002] [<000000000017bbaa>] __might_sleep+0x72/0x90
[ 4050.265010] irq event stamp: 7039
[ 4050.265020] hardirqs last enabled at (7047): [<00000000001cee7a>] console_unlock+0x6d2/0x740
[ 4050.265029] hardirqs last disabled at (7054): [<00000000001ce87e>] console_unlock+0xd6/0x740
[ 4050.265040] softirqs last enabled at (6416): [<0000000000b8fe26>] __udelay+0xb6/0x100
[ 4050.265049] softirqs last disabled at (6415): [<0000000000b8fe06>] __udelay+0x96/0x100
[ 4050.265057] ---[ end trace d04a07d39d99a9f9 ]---Let's fix this as described in the article
https://lwn.net/Articles/628628/.
--- drivers/vfio/vfio.c | 30 ++++++++++-------------------- 1 file changed, 10 insertions(+), 20 deletions(-)
drivers/vfio/vfio.c +10 -20
@@ -34,6 +34,7 @@#include <linux/uaccess.h> #include <linux/vfio.h> #include <linux/wait.h> +#include <linux/sched/signal.h> #define DRIVER_VERSION "0.3"#define DRIVER_AUTHOR "Alex Williamson <[email protected]>"
@@ -904,30 +905,17 @@ void *vfio_device_data(struct vfio_device *device) }EXPORT_SYMBOL_GPL (vfio_device_data); -/* Given a referenced group, check if it contains the device */ -static bool vfio_dev_present (struct vfio_group *group,struct device *dev) -{ -struct vfio_device *device; - - device =vfio_group_get_device (group, dev); -if (!device) -return false; - -vfio_device_put (device); -return true; -} -/* * Decrement the device reference count and wait for the device to be * removed. Open file descriptors for the device... */ void *vfio_del_group_dev (struct device *dev) { +DEFINE_WAIT_FUNC (wait, woken_wake_function);struct vfio_device *device =dev_get_drvdata (dev);struct vfio_group *group = device->group;void *device_data = device->device_data;struct vfio_unbound_dev *unbound;unsigned int i =0 ; -long ret;bool interrupted = false;/*
@@ -964,6 +952,8 @@ void *vfio_del_group_dev(struct device *dev)* interval with counter to allow the driver to take escalating * measures to release the device if it has the ability to do so. */ +add_wait_queue (&vfio.release_q, &wait); + do { device = vfio_group_get_device(group, dev); if (!device)
@@ -975,12 +965,10 @@ void *vfio_del_group_dev(struct device *dev)vfio_device_put (device);if (interrupted) { - ret =wait_event_timeout (vfio.release_q, - !vfio_dev_present (group, dev),HZ *10 ); +wait_woken (&wait,TASK_UNINTERRUPTIBLE ,HZ *10 ); }else { - ret =wait_event_interruptible_timeout (vfio.release_q, - !vfio_dev_present (group, dev),HZ *10 ); -if (ret == -ERESTARTSYS ) { +wait_woken (&wait,TASK_INTERRUPTIBLE ,HZ *10 ); +if (signal_pending (current)) { interrupted = true;dev_warn (dev, "Device is currently in use, task"
@@ -989,8 +977,10 @@ void *vfio_del_group_dev(struct device *dev) current->comm, task_pid_nr(current)); } } - }while (ret <=0 ); + }while (1 ); + +remove_wait_queue (&vfio.release_q, &wait);/* * In order to support multiple devices per group, devices can be * plucked from the group while other devices in the group are still
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 89/155 iommu/arm-smmu-v3: Dont disable SMMU in kdump kernel
In reply to Greg Kroah-Hartman[ Upstream commit 3f54c447df34ff9efac7809a4a80fd3208efc619 ]
Disabling the SMMU when probing from within a kdump kernel so that all incoming transactions are terminated can prevent the core of the crashed kernel from being transferred off the machine if all I/O devices are behind the SMMU.
Instead, continue to probe the SMMU after it is disabled so that we can reinitialise it entirely and re-attach the DMA masters as they are reset. Since the kdump kernel may not have drivers for all of the active DMA masters, we suppress fault reporting to avoid spamming the console and swamping the IRQ threads.
--- drivers/iommu/arm-smmu-v3.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-)
drivers/iommu/arm-smmu-v3.c +4 -6
@@ -2454,13 +2454,9 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)/* Clear CR0 and sync (disables SMMU and queue processing) */ reg =readl_relaxed (smmu->base +ARM_SMMU_CR0 );if (reg &CR0_SMMUEN ) { -if (is_kdump_kernel ()) { -arm_smmu_update_gbpa (smmu,GBPA_ABORT ,0 ); -arm_smmu_device_disable (smmu); -return -EBUSY ; - } -dev_warn (smmu->dev,"SMMU currently enabled! Resetting...\n" ); +WARN_ON (is_kdump_kernel () && !disable_bypass); +arm_smmu_update_gbpa (smmu,GBPA_ABORT ,0 ); } ret =arm_smmu_device_disable (smmu);
@@ -2553,6 +2549,8 @@ static int arm_smmu_device_reset(struct arm_smmu_device *smmu, bool bypass)return ret; } +if (is_kdump_kernel ()) + enables &= ~(CR0_EVTQEN |CR0_PRIQEN );/* Enable the SMMU interface, or ensure bypass */ if (!bypass || disable_bypass) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 90/155 switchtec: Fix unintended mask of MRPC event
In reply to Greg Kroah-Hartman[ Upstream commit 083c1b5e50b701899dc32445efa8b153685260d5 ]
When running application tool switchtec-user's firmware update and event wait commands concurrently, sometimes the firmware update speed reduced significantly.
It is because when the MRPC event happened after MRPC event occurrence check but before the event mask loop reaches its header register in event ISR, the MRPC event would be masked unintentionally. Since there's no chance to enable it again except for a module reload, all the following MRPC execution completion checks time out.
Fix this bug by skipping the mask operation for MRPC event in event ISR, same as what we already do for LINK event.
--- drivers/pci/switch/switchtec.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/pci/switch/switchtec.c +2 -1
@@ -1162,7 +1162,8 @@ static int mask_event(struct switchtec_dev *stdev, int eid, int idx)if (!(hdr &SWITCHTEC_EVENT_OCCURRED && hdr &SWITCHTEC_EVENT_EN_IRQ ))return 0 ; -if (eid ==SWITCHTEC_IOCTL_EVENT_LINK_STATE ) +if (eid ==SWITCHTEC_IOCTL_EVENT_LINK_STATE || + eid ==SWITCHTEC_IOCTL_EVENT_MRPC_COMP )return 0 ;dev_dbg (&stdev->dev,"%s: %d %d %x\n" , __func__, eid, idx, hdr);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 91/155 net: thunderbolt: Unregister ThunderboltIP protocol handler when suspending
In reply to Greg Kroah-Hartman[ Upstream commit 9872760eb7b1d4f6066ad8b560714a5d0a728fdb ]
The XDomain protocol messages may start as soon as Thunderbolt control channel is started. This means that if the other host starts sending ThunderboltIP packets early enough they will be passed to the network driver which then gets confused because its resume hook is not called yet.
Fix this by unregistering the ThunderboltIP protocol handler when suspending and registering it back on resume.
--- drivers/net/thunderbolt.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/thunderbolt.c +3 -0
@@ -1282,6 +1282,7 @@ static int __maybe_unused tbnet_suspend(struct device *dev)tbnet_tear_down (net, true); } +tb_unregister_protocol_handler (&net->handler);return 0 ; }
@@ -1290,6 +1291,8 @@ static int __maybe_unused tbnet_resume(struct device *dev)struct tb_service *svc =tb_to_service (dev);struct tbnet *net =tb_service_get_drvdata (svc); +tb_register_protocol_handler (&net->handler); +netif_carrier_off (net->dev);if (netif_running (net->dev)) {netif_device_attach (net->dev);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 92/155 x86/PCI: Fix PCI IRQ routing table memory leak
In reply to Greg Kroah-Hartman[ Upstream commit ea094d53580f40c2124cef3d072b73b2425e7bfd ]
In pcibios_irq_init(), the PCI IRQ routing table 'pirq_table' is first found through pirq_find_routing_table(). If the table is not found and CONFIG_PCI_BIOS is defined, the table is then allocated in pcibios_get_irq_routing_table() using kmalloc(). Later, if the I/O APIC is used, this table is actually not used. In that case, the allocated table is not freed, which is a memory leak.
Free the allocated table if it is not used.
[bhelgaas: added Ingo's reviewed-by, since the only change since v1 was to use the irq_routing_table local variable name he suggested]
--- arch/x86/pci/irq.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
arch/x86/pci/irq.c +8 -2
@@ -1119,6 +1119,8 @@ static const struct dmi_system_id pciirq_dmi_table[] __initconst = {void __init pcibios_irq_init (void ) { +struct irq_routing_table *rtable =NULL ; +DBG (KERN_DEBUG "PCI: IRQ init\n" );if (raw_pci_ops ==NULL )
@@ -1129,8 +1131,10 @@ void __init pcibios_irq_init(void) pirq_table =pirq_find_routing_table ();#ifdef CONFIG_PCI_BIOS -if (!pirq_table && (pci_probe &PCI_BIOS_IRQ_SCAN )) +if (!pirq_table && (pci_probe &PCI_BIOS_IRQ_SCAN )) { pirq_table =pcibios_get_irq_routing_table (); + rtable = pirq_table; + }#endif if (pirq_table) {pirq_peer_trick ();
@@ -1145,8 +1149,10 @@ void __init pcibios_irq_init(void)* If we're using the I/O APIC, avoid using the PCI IRQ * routing table */ -if (io_apic_assign_pci_irqs) +if (io_apic_assign_pci_irqs) { +kfree (rtable); pirq_table =NULL ; + } } x86_init.pci.fixup_irqs ();
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 93/155 soc/tegra: pmc: Remove reset sysfs entries on error
In reply to Greg Kroah-Hartman[ Upstream commit a46b51cd2a57d52d5047e1d48240536243eeab34 ]
Commit 5f84bb1a4099 ("soc/tegra: pmc: Add sysfs entries for reset info") added sysfs entries for Tegra reset source and level. However, these sysfs are not removed on error and so if the registering of PMC device is probe deferred, then the next time we attempt to probe the PMC device warnings such as the following will be displayed on boot ...
sysfs: cannot create duplicate filename '/devices/platform/7000e400.pmc/reset_reason'
Fix this by calling device_remove_file() for each sysfs entry added on failure. Note that we call device_remove_file() unconditionally without checking if the sysfs entry was created in the first place, but this should be OK because kernfs_remove_by_name_ns() will fail silently.
--- drivers/soc/tegra/pmc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/soc/tegra/pmc.c +4 -1
@@ -1999,7 +1999,7 @@ static int tegra_pmc_probe(struct platform_device *pdev)if (IS_ENABLED (CONFIG_DEBUG_FS )) { err =tegra_powergate_debugfs_init ();if (err <0 ) -return err; + goto cleanup_sysfs; } err =register_restart_handler (&tegra_pmc_restart_handler);
@@ -2030,6 +2030,9 @@ cleanup_restart_handler:unregister_restart_handler (&tegra_pmc_restart_handler); cleanup_debugfs:debugfs_remove (pmc->debugfs); +cleanup_sysfs: +device_remove_file (&pdev->dev, &dev_attr_reset_reason); +device_remove_file (&pdev->dev, &dev_attr_reset_level);return err; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 94/155 i40e: Queues are reserved despite "Invalid argument" error
In reply to Greg Kroah-Hartman[ Upstream commit 3e957b377bf4262aec2dd424f28ece94e36814d4 ]
Added a new local variable in the i40e_setup_tc function named old_queue_pairs so num_queue_pairs can be restored to the correct value in case configuring queue channels fails. Additionally, moved the exit label in the i40e_setup_tc function so the if (need_reset) block can be executed.
Also, fixed data packing in the i40e_setup_tc function.
--- drivers/net/ethernet/intel/i40e/i40e_main.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/intel/i40e/i40e_main.c +3 -0
@@ -6854,10 +6854,12 @@ static int i40e_setup_tc(struct net_device *netdev, void *type_data)struct i40e_pf *pf = vsi->back;u8 enabled_tc =0 , num_tc, hw;bool need_reset = false; +int old_queue_pairs;int ret = -EINVAL ;u16 mode;int i; + old_queue_pairs = vsi->num_queue_pairs; num_tc = mqprio_qopt->qopt.num_tc; hw = mqprio_qopt->qopt.hw; mode = mqprio_qopt->mode;
@@ -6958,6 +6960,7 @@ config_tc: } ret =i40e_configure_queue_channels (vsi);if (ret) { + vsi->num_queue_pairs = old_queue_pairs;netdev_info (netdev,"Failed configuring queue channels\n" ); need_reset = true;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 95/155 power: supply: cpcap-battery: Fix signed counter sample register
In reply to Greg Kroah-Hartman[ Upstream commit c68b901ac4fa969db8917b6a9f9b40524a690d20 ]
The accumulator sample register is signed 32-bits wide register on droid 4. And only the earlier version of cpcap has a signed 24-bits wide register. We're currently passing it around as unsigned, so let's fix that and use sign_extend32() for the earlier revision.
--- drivers/power/supply/cpcap-battery.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/power/supply/cpcap-battery.c +6 -5
@@ -82,7 +82,7 @@ struct cpcap_battery_config { };struct cpcap_coulomb_counter_data { -s32 sample;/* 24-bits */ +s32 sample;/* 24 or 32 bits */ s32 accumulator;s16 offset;/* 10-bits */ };
@@ -213,7 +213,7 @@ static int cpcap_battery_get_current(struct cpcap_battery_ddata *ddata)* TI or ST coulomb counter in the PMIC. */ static int cpcap_battery_cc_raw_div (struct cpcap_battery_ddata *ddata, -u32 sample,s32 accumulator, +s32 sample,s32 accumulator,s16 offset,u32 divider) {s64 acc;
@@ -224,7 +224,6 @@ static int cpcap_battery_cc_raw_div(struct cpcap_battery_ddata *ddata,if (!divider)return 0 ; - sample &=0xffffff ;/* 24-bits, unsigned */ offset &=0x7ff ;/* 10-bits, signed */ switch (ddata->vendor) {
@@ -259,7 +258,7 @@ static int cpcap_battery_cc_raw_div(struct cpcap_battery_ddata *ddata,/* 3600000μAms = 1μAh */ static int cpcap_battery_cc_to_uah (struct cpcap_battery_ddata *ddata, -u32 sample,s32 accumulator, +s32 sample,s32 accumulator,s16 offset) { return cpcap_battery_cc_raw_div(ddata, sample,
@@ -268,7 +267,7 @@ static int cpcap_battery_cc_to_uah(struct cpcap_battery_ddata *ddata, }static int cpcap_battery_cc_to_ua (struct cpcap_battery_ddata *ddata, -u32 sample,s32 accumulator, +s32 sample,s32 accumulator,s16 offset) { return cpcap_battery_cc_raw_div(ddata, sample,
@@ -312,6 +311,8 @@ cpcap_battery_read_accumulated(struct cpcap_battery_ddata *ddata,/* Sample value CPCAP_REG_CCS1 & 2 */ ccd->sample = (buf[1 ] &0x0fff ) <<16 ; ccd->sample |= buf[0 ]; +if (ddata->vendor ==CPCAP_VENDOR_TI ) + ccd->sample =sign_extend32 (24 , ccd->sample);/* Accumulator value CPCAP_REG_CCA1 & 2 */ ccd->accumulator = ((s16 )buf[3 ]) <<16 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 96/155 platform/chrome: cros_ec_proto: check for NULL transfer function
In reply to Greg Kroah-Hartman[ Upstream commit 94d4e7af14a1170e34cf082d92e4c02de9e9fb88 ]
As new transfer mechanisms are added to the EC codebase, they may not support v2 of the EC protocol.
If the v3 initial handshake transfer fails, the kernel will try and call cmd_xfer as a fallback. If v2 is not supported, cmd_xfer will be NULL, and the code will end up causing a kernel panic.
Add a check for NULL before calling the transfer function, along with a helpful comment explaining how one might end up in this situation.
--- drivers/platform/chrome/cros_ec_proto.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/platform/chrome/cros_ec_proto.c +11 -0
@@ -56,6 +56,17 @@ static int send_command(struct cros_ec_device *ec_dev,else xfer_fxn = ec_dev->cmd_xfer; +if (!xfer_fxn) { +/* +* This error can happen if a communication error happened and +* the EC is trying to use protocol v2, on an underlying +* communication mechanism that does not support v2. +*/ +dev_err_once (ec_dev->dev, +"missing EC transfer API, cannot send command\n" ); +return -EIO ; + } + ret = (*xfer_fxn)(ec_dev, msg);if (msg->result ==EC_RES_IN_PROGRESS ) {int i;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 97/155 PCI: keystone: Invoke phy_reset() API before enabling PHY
In reply to Greg Kroah-Hartman[ Upstream commit b22af42b3e57c3a49a4c4a54c7d8a1363af75e90 ]
SERDES connected to the PCIe controller in AM654 requires power on reset enable (POR_EN) to be set in the SERDES. The SERDES driver sets POR_EN in the reset ops and it has to be invoked before init or enable ops. In order for SERDES driver to set POR_EN, invoke the phy_reset() API in pci-keystone driver.
--- drivers/pci/controller/dwc/pci-keystone.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/pci/controller/dwc/pci-keystone.c +4 -0
@@ -873,6 +873,10 @@ static int ks_pcie_enable_phy(struct keystone_pcie *ks_pcie)int num_lanes = ks_pcie->num_lanes;for (i =0 ; i < num_lanes; i++) { + ret =phy_reset (ks_pcie->phy[i]); +if (ret <0 ) + goto err_phy; + ret =phy_init (ks_pcie->phy[i]);if (ret <0 ) goto err_phy;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 98/155 PCI: keystone: Prevent ARM32 specific code to be compiled for ARM64
In reply to Greg Kroah-Hartman[ Upstream commit f316a2b53cd7f37963ae20ec7072eb27a349a4ce ]
hook_fault_code() is an ARM32 specific API for hooking into data abort.
AM65X platforms (that integrate ARM v8 cores and select CONFIG_ARM64 as arch) rely on pci-keystone.c but on them the enumeration of a non-present BDF does not trigger a bus error, so the fixup exception provided by calling hook_fault_code() is not needed and can be guarded with CONFIG_ARM.
--- drivers/pci/controller/dwc/pci-keystone.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/pci/controller/dwc/pci-keystone.c +4 -0
@@ -705,6 +705,7 @@ static void ks_pcie_setup_interrupts(struct keystone_pcie *ks_pcie)ks_pcie_enable_error_irq (ks_pcie); } +#ifdef CONFIG_ARM /* * When a PCI device does not exist during config cycles, keystone host gets a * bus error instead of returning 0xffffffff. This handler always returns 0
@@ -724,6 +725,7 @@ static int ks_pcie_fault(unsigned long addr, unsigned int fsr, return 0; } +#endif static int __init ks_pcie_init_id (struct keystone_pcie *ks_pcie) {
@@ -766,12 +768,14 @@ static int __init ks_pcie_host_init(struct pcie_port *pp)if (ret <0 )return ret; +#ifdef CONFIG_ARM /* * PCIe access errors that result into OCP errors are caught by ARM as * "External aborts" */ hook_fault_code (17 , ks_pcie_fault,SIGBUS ,0 ,"Asynchronous external abort" ); +#endif return 0 ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 99/155 soc: mediatek: pwrap: Zero initialize rdata in pwrap_init_cipher
In reply to Greg Kroah-Hartman[ Upstream commit 89e28da82836530f1ac7a3a32fecc31f22d79b3e ]
When building with -Wsometimes-uninitialized, Clang warns:
drivers/soc/mediatek/mtk-pmic-wrap.c:1358:6: error: variable 'rdata' is used uninitialized whenever '||' condition is true [-Werror,-Wsometimes-uninitialized]
If pwrap_write returns non-zero, pwrap_read will not be called to initialize rdata, meaning that we will use some random uninitialized stack value in our print statement. Zero initialize rdata in case this happens.
--- drivers/soc/mediatek/mtk-pmic-wrap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/soc/mediatek/mtk-pmic-wrap.c +1 -1
@@ -1281,7 +1281,7 @@ static bool pwrap_is_pmic_cipher_ready(struct pmic_wrapper *wrp)static int pwrap_init_cipher (struct pmic_wrapper *wrp) {int ret; -u32 rdata; +u32 rdata =0 ;pwrap_writel (wrp,0x1 ,PWRAP_CIPHER_SWRST );pwrap_writel (wrp,0x0 ,PWRAP_CIPHER_SWRST );
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 100/155 clk: rockchip: Turn on "aclk_dmac1" for suspend on rk3288
In reply to Greg Kroah-Hartman[ Upstream commit 57a20248ef3e429dc822f0774bc4e00136c46c83 ]
Experimentally it can be seen that going into deep sleep (specifically setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1) appears to fail unless "aclk_dmac1" is on. The failure is that the system never signals that it made it into suspend on the GLOBAL_PWROFF pin and it just hangs.
NOTE that it's confirmed that it's the actual suspend that fails, not one of the earlier calls to read/write registers. Specifically if you comment out the "PMU_GLOBAL_INT_DISABLE" setting in rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in rockchip_lpmode_enter() then you can exercise the whole suspend path without any crashing.
This is currently not a problem with suspend upstream because there is no current way to exercise the deep suspend code. However, anyone trying to make it work will run into this issue.
This was not a problem on shipping rk3288-based Chromebooks because those devices all ran on an old kernel based on 3.14. On that kernel "aclk_dmac1" appears to be left on all the time.
There are several ways to skin this problem.
A) We could add "aclk_dmac1" to the list of critical clocks and that apperas to work, but presumably that wastes power.
B) We could keep a list of "struct clk" objects to enable at suspend time in clk-rk3288.c and use the standard clock APIs.
C) We could make the rk3288-pmu driver keep a list of clocks to enable at suspend time. Presumably this would require a dts and bindings change.
D) We could just whack the clock on in the existing syscore suspend function where we whack a bunch of other clocks. This is particularly easy because we know for sure that the clock's only parent ("aclk_cpu") is a critical clock so we don't need to do anything more than ungate it.
In this case I have chosen D) because it seemed like the least work, but any of the other options would presumably also work fine.
--- drivers/clk/rockchip/clk-rk3288.c | 11 +++++++++++ 1 file changed, 11 insertions(+)
drivers/clk/rockchip/clk-rk3288.c +11 -0
@@ -856,6 +856,9 @@ static const int rk3288_saved_cru_reg_ids[] = {RK3288_CLKSEL_CON (10 ),RK3288_CLKSEL_CON (33 ),RK3288_CLKSEL_CON (37 ), + +/* We turn aclk_dmac1 on for suspend; this will restore it */ + RK3288_CLKGATE_CON(10), };static u32 rk3288_saved_cru_regs[ARRAY_SIZE (rk3288_saved_cru_reg_ids)];
@@ -871,6 +874,14 @@ static int rk3288_clk_suspend(void)readl_relaxed (rk3288_cru_base + reg_id); } +/* +* Going into deep sleep (specifically setting PMU_CLR_DMA in +* RK3288_PMU_PWRMODE_CON1) appears to fail unless +* "aclk_dmac1" is on. +*/ +writel_relaxed (1 << (12 +16 ), + rk3288_cru_base +RK3288_CLKGATE_CON (10 )); +/* * Switch PLLs other than DPLL (for SDRAM) to slow mode to * avoid crashes on resume. The Mask ROM on the system will
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 101/155 usb: ohci-da8xx: disable the regulator if the overcurrent irq fired
In reply to Greg Kroah-Hartman[ Upstream commit d327330185f192411be80563a3c8398f4538cdb2 ]
Historically the power supply management in this driver has been handled in two separate places in parallel. Device-tree users simply defined an appropriate regulator, while two boards with no DT support (da830-evm and omapl138-hawk) passed functions defined in their respective board files over platform data. These functions simply used legacy GPIO calls to watch the oc GPIO for interrupts and disable the vbus GPIO when the irq fires.
Commit d193abf1c913 ("usb: ohci-da8xx: add vbus and overcurrent gpios") updated these GPIO calls to the modern API and moved them inside the driver.
This however is not the optimal solution for the vbus GPIO which should be modeled as a fixed regulator that can be controlled with a GPIO.
In order to keep the overcurrent protection available once we move the board files to using fixed regulators we need to disable the enable_reg regulator when the overcurrent indicator interrupt fires. Since we cannot call regulator_disable() from interrupt context, we need to switch to using a oneshot threaded interrupt.
--- drivers/usb/host/ohci-da8xx.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-)
drivers/usb/host/ohci-da8xx.c +17 -5
@@ -206,12 +206,23 @@ static int ohci_da8xx_regulator_event(struct notifier_block *nb,return 0 ; } -static irqreturn_t ohci_da8xx_oc_handler (int irq,void *data) +static irqreturn_t ohci_da8xx_oc_thread (int irq,void *data) {struct da8xx_ohci_hcd *da8xx_ohci = data; +struct device *dev = da8xx_ohci->hcd->self.controller; +int ret; -if (gpiod_get_value (da8xx_ohci->oc_gpio)) -gpiod_set_value (da8xx_ohci->vbus_gpio,0 ); +if (gpiod_get_value_cansleep (da8xx_ohci->oc_gpio)) { +if (da8xx_ohci->vbus_gpio) { +gpiod_set_value_cansleep (da8xx_ohci->vbus_gpio,0 ); + }else if (da8xx_ohci->vbus_reg) { + ret =regulator_disable (da8xx_ohci->vbus_reg); +if (ret) +dev_err (dev, +"Failed to disable regulator: %d\n" , + ret); + } + }return IRQ_HANDLED ; }
@@ -438,8 +449,9 @@ static int ohci_da8xx_probe(struct platform_device *pdev)if (oc_irq <0 ) goto err; - error =devm_request_irq (dev, oc_irq, ohci_da8xx_oc_handler, -IRQF_TRIGGER_RISING |IRQF_TRIGGER_FALLING , + error =devm_request_threaded_irq (dev, oc_irq,NULL , + ohci_da8xx_oc_thread,IRQF_TRIGGER_RISING | +IRQF_TRIGGER_FALLING |IRQF_ONESHOT ,"OHCI over-current indicator" , da8xx_ohci);if (error) goto err;
Signature · 1 line
2.20.1
Re: [PATCH 5.1 101/155] usb: ohci-da8xx: disable the regulator if the overcurrent irq fired
Hi,
Quoted 23 lines · Greg Kroah-Hartman
[ Upstream commit
d327330185f192411be80563a3c8398f4538cdb2]Historically the power supply management in this driver has been handled in two separate places in parallel. Device-tree users simply defined an appropriate regulator, while two boards with no DT support (da830-evm and omapl138-hawk) passed functions defined in their respective board files over platform data. These functions simply used legacy GPIO calls to watch the oc GPIO for interrupts and disable the vbus GPIO when the irq fires.
Commit
d193abf1c913("usb: ohci-da8xx: add vbus and overcurrent gpios") updated these GPIO calls to the modern API and moved them inside the driver.This however is not the optimal solution for the vbus GPIO which should be modeled as a fixed regulator that can be controlled with a GPIO.
In order to keep the overcurrent protection available once we move the board files to using fixed regulators we need to disable the
enable_regregulator when the overcurrent indicator interrupt fires. Since we cannot callregulator_disable()from interrupt context, we need to switch to using a oneshot threaded interrupt.
Quoted 4 lines
Acked-by Alan Stern <[email protected]>Signed-off-by Bartosz Golaszewski <[email protected]>Signed-off-by Sekhar Nori <[email protected]>Signed-off-by Sasha Levin <[email protected]>
This is a preparatory patch for some clean-up. This should not be backported to stable.
Thanks,
Sekhar
Greg Kroah-Hartman
maintainerPATCH 102/155 iommu/vt-d: Flush IOTLB for untrusted device in time
In reply to Greg Kroah-Hartman[ Upstream commit f7b0c4ce8cb3c09cb3cbfc0c663268bf99e5fa9c ]
By default, for performance consideration, Intel IOMMU driver won't flush IOTLB immediately after a buffer is unmapped. It schedules a thread and flushes IOTLB in a batched mode. This isn't suitable for untrusted device since it still can access the memory even if it isn't supposed to do so.
--- drivers/iommu/intel-iommu.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/iommu/intel-iommu.c +5 -1
@@ -3736,6 +3736,7 @@ static void intel_unmap(struct device *dev, dma_addr_t dev_addr, size_t size)unsigned long iova_pfn;struct intel_iommu *iommu;struct page *freelist; +struct pci_dev *pdev =NULL ;if (iommu_no_mapping (dev))return ;
@@ -3751,11 +3752,14 @@ static void intel_unmap(struct device *dev, dma_addr_t dev_addr, size_t size) start_pfn =mm_to_dma_pfn (iova_pfn); last_pfn = start_pfn + nrpages -1 ; +if (dev_is_pci (dev)) + pdev =to_pci_dev (dev); +dev_dbg (dev,"Device unmapping: pfn %lx-%lx\n" , start_pfn, last_pfn); freelist =domain_unmap (domain, start_pfn, last_pfn); -if (intel_iommu_strict) { +if (intel_iommu_strict || (pdev && pdev->untrusted)) {iommu_flush_iotlb_psi (iommu, domain, start_pfn, nrpages, !freelist,0 );/* free iova */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 103/155 soc: rockchip: Set the proper PWM for rk3288
In reply to Greg Kroah-Hartman[ Upstream commit bbdc00a7de24cc90315b1775fb74841373fe12f7 ]
The rk3288 SoC has two PWM implementations available, the "old" implementation and the "new" one. You can switch between the two of them by flipping a bit in the grf.
The "old" implementation is the default at chip power up but isn't the one that's officially supposed to be used. ...and, in fact, the driver that gets selected in Linux using the rk3288 device tree only supports the "new" implementation.
Long ago I tried to get a switch to the right IP block landed in the PWM driver (search for "rk3288: Switch to use the proper PWM IP") but that got rejected. In the mean time the grf has grown a full-fledged driver that already sets other random bits like this. That means we can now get the fix landed.
For those wondering how things could have possibly worked for the last 4.5 years, folks have mostly been relying on the bootloader to set this bit. ...but occasionally folks have pointed back to my old patch series [1] in downstream kernels.
[1] https://www.mail-archive.com/[email protected]/msg1391597.html
--- drivers/soc/rockchip/grf.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/soc/rockchip/grf.c +2 -0
@@ -66,9 +66,11 @@ static const struct rockchip_grf_info rk3228_grf __initconst = { };#define RK3288_GRF_SOC_CON0 0x244 +#define RK3288_GRF_SOC_CON2 0x24cstatic const struct rockchip_grf_value rk3288_defaults[]__initconst = { {"jtag switching" ,RK3288_GRF_SOC_CON0 ,HIWORD_UPDATE (0 ,1 ,12 ) }, + {"pwm select" ,RK3288_GRF_SOC_CON2 ,HIWORD_UPDATE (1 ,1 ,0 ) }, };static const struct rockchip_grf_info rk3288_grf__initconst = {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 104/155 arm64: dts: imx8mq: Mark iomuxc_gpr as i.MX6Q compatible
In reply to Greg Kroah-Hartman[ Upstream commit beea0f22566cb32c35de89ab0980852b5bbc1c60 ]
Mark iomuxc_gpr as compatible with "fsl,imx6q-iomuxc-gpr" in order for to allow i.MX6 PCIe driver to use it.
--- arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm64/boot/dts/freescale/imx8mq.dtsi +1 -1
@@ -240,7 +240,7 @@ }; iomuxc_gpr: syscon@30340000 { - compatible = "fsl,imx8mq-iomuxc-gpr", "syscon"; + compatible = "fsl,imx8mq-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon"; reg = <0x30340000 0x10000>; };
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 105/155 ARM: dts: imx51: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
In reply to Greg Kroah-Hartman[ Upstream commit 918bbde8085ae147a43dcb491953e0dd8f3e9d6a ]
Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio.
--- arch/arm/boot/dts/imx51.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx51.dtsi +1 -1
@@ -489,7 +489,7 @@ reg = <0x83fb0000 0x4000>; interrupts = <6>; clocks = <&clks IMX5_CLK_SDMA_GATE>, - <&clks IMX5_CLK_SDMA_GATE>; + <&clks IMX5_CLK_AHB>; clock-names = "ipg", "ahb"; #dma-cells = <3>; fsl,sdma-ram-script-name = "imx/sdma/sdma-imx51.bin";
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 106/155 ARM: dts: imx50: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
In reply to Greg Kroah-Hartman[ Upstream commit b7b4fda2636296471e29b78c2aa9535d7bedb7a0 ]
Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio.
--- arch/arm/boot/dts/imx50.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx50.dtsi +1 -1
@@ -411,7 +411,7 @@ reg = <0x63fb0000 0x4000>; interrupts = <6>; clocks = <&clks IMX5_CLK_SDMA_GATE>, - <&clks IMX5_CLK_SDMA_GATE>; + <&clks IMX5_CLK_AHB>; clock-names = "ipg", "ahb"; #dma-cells = <3>; fsl,sdma-ram-script-name = "imx/sdma/sdma-imx50.bin";
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 107/155 ARM: dts: imx53: Specify IMX5_CLK_IPG as "ahb" clock to SDMA
In reply to Greg Kroah-Hartman[ Upstream commit 28c168018e0902c67eb9c60d0fc4c8aa166c4efe ]
Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX5_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX5_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio.
--- arch/arm/boot/dts/imx53.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx53.dtsi +1 -1
@@ -702,7 +702,7 @@ reg = <0x63fb0000 0x4000>; interrupts = <6>; clocks = <&clks IMX5_CLK_SDMA_GATE>, - <&clks IMX5_CLK_SDMA_GATE>; + <&clks IMX5_CLK_AHB>; clock-names = "ipg", "ahb"; #dma-cells = <3>; fsl,sdma-ram-script-name = "imx/sdma/sdma-imx53.bin";
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 108/155 ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ahb" clock to SDMA
In reply to Greg Kroah-Hartman[ Upstream commit cc839d0f8c284fcb7591780b568f13415bbb737c ]
Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6SL_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6SL_CLK_AHB as "ahb" clock for SDMA, to avoid detecting incorrect clock ratio.
--- arch/arm/boot/dts/imx6sl.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx6sl.dtsi +1 -1
@@ -741,7 +741,7 @@ reg = <0x020ec000 0x4000>; interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6SL_CLK_SDMA>, - <&clks IMX6SL_CLK_SDMA>; + <&clks IMX6SL_CLK_AHB>; clock-names = "ipg", "ahb"; #dma-cells = <3>; /* imx6sl reuses imx6q sdma firmware */
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 109/155 ARM: dts: imx6sll: Specify IMX6SLL_CLK_IPG as "ipg" clock to SDMA
In reply to Greg Kroah-Hartman[ Upstream commit c5ed5daa65d5f665e666b76c3dbfa503066defde ]
Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6SLL_CLK_SDMA result in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6SLL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio.
--- arch/arm/boot/dts/imx6sll.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx6sll.dtsi +1 -1
@@ -621,7 +621,7 @@ compatible = "fsl,imx6sll-sdma", "fsl,imx35-sdma"; reg = <0x020ec000 0x4000>; interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX6SLL_CLK_SDMA>, + clocks = <&clks IMX6SLL_CLK_IPG>, <&clks IMX6SLL_CLK_SDMA>; clock-names = "ipg", "ahb"; #dma-cells = <3>;
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 110/155 ARM: dts: imx7d: Specify IMX7D_CLK_IPG as "ipg" clock to SDMA
In reply to Greg Kroah-Hartman[ Upstream commit 412b032a1dc72fc9d1c258800355efa6671b6315 ]
Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX7D_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX7D_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio.
--- arch/arm/boot/dts/imx7s.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/imx7s.dtsi +2 -2
@@ -1067,8 +1067,8 @@ compatible = "fsl,imx7d-sdma", "fsl,imx35-sdma"; reg = <0x30bd0000 0x10000>; interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX7D_SDMA_CORE_CLK>, - <&clks IMX7D_AHB_CHANNEL_ROOT_CLK>; + clocks = <&clks IMX7D_IPG_ROOT_CLK>, + <&clks IMX7D_SDMA_CORE_CLK>; clock-names = "ipg", "ahb"; #dma-cells = <3>; fsl,sdma-ram-script-name = "imx/sdma/sdma-imx7d.bin";
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 111/155 ARM: dts: imx6ul: Specify IMX6UL_CLK_IPG as "ipg" clock to SDMA
In reply to Greg Kroah-Hartman[ Upstream commit 7b3132ecefdd1fcdf6b86e62021d0e55ea8034db ]
Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6UL_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6UL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio.
--- arch/arm/boot/dts/imx6ul.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx6ul.dtsi +1 -1
@@ -708,7 +708,7 @@ "fsl,imx35-sdma"; reg = <0x020ec000 0x4000>; interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX6UL_CLK_SDMA>, + clocks = <&clks IMX6UL_CLK_IPG>, <&clks IMX6UL_CLK_SDMA>; clock-names = "ipg", "ahb"; #dma-cells = <3>;
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 112/155 ARM: dts: imx6sx: Specify IMX6SX_CLK_IPG as "ipg" clock to SDMA
In reply to Greg Kroah-Hartman[ Upstream commit 8979117765c19edc3b01cc0ef853537bf93eea4b ]
Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6SX_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality. Fix the code to specify IMX6SX_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio.
--- arch/arm/boot/dts/imx6sx.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx6sx.dtsi +1 -1
@@ -820,7 +820,7 @@ compatible = "fsl,imx6sx-sdma", "fsl,imx6q-sdma"; reg = <0x020ec000 0x4000>; interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX6SX_CLK_SDMA>, + clocks = <&clks IMX6SX_CLK_IPG>, <&clks IMX6SX_CLK_SDMA>; clock-names = "ipg", "ahb"; #dma-cells = <3>;
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 113/155 ARM: dts: imx6qdl: Specify IMX6QDL_CLK_IPG as "ipg" clock to SDMA
In reply to Greg Kroah-Hartman[ Upstream commit b14c872eebc501b9640b04f4a152df51d6eaf2fc ]
Since 25aaa75df1e6 SDMA driver uses clock rates of "ipg" and "ahb" clock to determine if it needs to configure the IP block as operating at 1:1 or 1:2 clock ratio (ACR bit in SDMAARM_CONFIG). Specifying both clocks as IMX6QDL_CLK_SDMA results in driver incorrectly thinking that ratio is 1:1 which results in broken SDMA funtionality(this at least breaks RAVE SP serdev driver on RDU2). Fix the code to specify IMX6QDL_CLK_IPG as "ipg" clock for SDMA, to avoid detecting incorrect clock ratio.
--- arch/arm/boot/dts/imx6qdl.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/imx6qdl.dtsi +1 -1
@@ -918,7 +918,7 @@ compatible = "fsl,imx6q-sdma", "fsl,imx35-sdma"; reg = <0x020ec000 0x4000>; interrupts = <0 2 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&clks IMX6QDL_CLK_SDMA>, + clocks = <&clks IMX6QDL_CLK_IPG>, <&clks IMX6QDL_CLK_SDMA>; clock-names = "ipg", "ahb"; #dma-cells = <3>;
Signature · 9 lines
2.20.1 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Greg Kroah-Hartman
maintainerPATCH 114/155 PCI: rpadlpar: Fix leaked device_node references in add/remove paths
In reply to Greg Kroah-Hartman[ Upstream commit fb26228bfc4ce3951544848555c0278e2832e618 ]
The find_dlpar_node() helper returns a device node with its reference incremented. Both the add and remove paths use this helper for find the appropriate node, but fail to release the reference when done.
Annotate the find_dlpar_node() helper with a comment about the incremented reference count and call of_node_put() on the obtained device_node in the add and remove paths. Also, fixup a reference leak in the find_vio_slot() helper where we fail to call of_node_put() on the vdevice node after we iterate over its children.
--- drivers/pci/hotplug/rpadlpar_core.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/pci/hotplug/rpadlpar_core.c +4 -0
@@ -51,6 +51,7 @@ static struct device_node *find_vio_slot_node(char *drc_name)if (rc ==0 )break ; } +of_node_put (parent);return dn; }
@@ -71,6 +72,7 @@ static struct device_node *find_php_slot_pci_node(char *drc_name,return np; } +/* Returns a device_node with its reference count incremented */ static struct device_node *find_dlpar_node (char *drc_name,int *node_type) {struct device_node *dn;
@@ -306,6 +308,7 @@ int dlpar_add_slot(char *drc_name) rc =dlpar_add_phb (drc_name, dn);break ; } +of_node_put (dn);printk (KERN_INFO "%s: slot %s added\n" ,DLPAR_MODULE_NAME , drc_name); exit:
@@ -439,6 +442,7 @@ int dlpar_remove_slot(char *drc_name) rc =dlpar_remove_pci_slot (drc_name, dn);break ; } +of_node_put (dn);vm_unmap_aliases ();printk (KERN_INFO "%s: slot %s removed\n" ,DLPAR_MODULE_NAME , drc_name);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 115/155 drm/amd/display: disable link before changing link settings
In reply to Greg Kroah-Hartman[ Upstream commit 15ae3b28f8ca406b449d36d36021e96b66aedb5d ]
[Why]
If link is already enabled at a different rate (for example 5.4 Gbps) then calling VBIOS command table to switch to a new rate (for example 2.7 Gbps) will not take effect.
This can lead to link training failure to occur.
[How]
If the requested link rate is different than the current link rate, the link must be disabled in order to re-enable at the new link rate.
In today's logic it is currently only impacting eDP since DP connection types will always disable the link during display detection, when initial link verification occurs.
--- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/gpu/drm/amd/display/dc/core/dc_link.c +9 -0
@@ -1399,6 +1399,15 @@ static enum dc_status enable_link_dp(/* get link settings for video mode timing */ decide_link_settings (stream, &link_settings); +/* If link settings are different than current and link already enabled +* then need to disable before programming to new rate. +*/ +if (link->link_status.link_active && + (link->cur_link_settings.lane_count != link_settings.lane_count || + link->cur_link_settings.link_rate != link_settings.link_rate)) { +dp_disable_link_phy (link, pipe_ctx->stream->signal); + } + pipe_ctx->stream_res.pix_clk_params.requested_sym_clk = link_settings.link_rate *LINK_RATE_REF_FREQ_IN_KHZ ; state->dccg->funcs->update_clocks (state->dccg, state, false);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 116/155 drm/amd/display: Use plane->color_space for dpp if specified
In reply to Greg Kroah-Hartman[ Upstream commit a1e07ba89d49581471d64c48152dbe03b42bd025 ]
[Why]
The input color space for the plane was previously ignored even if it was set.
If a limited range YUV format was given to DC then the wrong color transformation matrix was being used since DC assumed that it was full range instead.
[How]
Respect the given color_space format for the plane if it isn't COLOR_SPACE_UNKNOWN. Otherwise, use the implicit default since DM didn't specify.
--- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c | 6 +++++- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +- 2 files changed, 6 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp.c +5 -1
@@ -392,6 +392,10 @@ void dpp1_cnv_setup (default :break ; } + +/* Set default color space based on format if none is given. */ + color_space = input_color_space ? input_color_space : color_space; +REG_SET (CNVC_SURFACE_PIXEL_FORMAT ,0 ,CNVC_SURFACE_PIXEL_FORMAT , pixel_format);REG_UPDATE (FORMAT_CONTROL ,FORMAT_CONTROL__ALPHA_EN , alpha_en);
@@ -403,7 +407,7 @@ void dpp1_cnv_setup (for (i =0 ; i <12 ; i++) tbl_entry.regval[i] = input_csc_color_matrix.matrix[i]; - tbl_entry.color_space = input_color_space; + tbl_entry.color_space = color_space;if (color_space >=COLOR_SPACE_YCBCR601 ) select =INPUT_CSC_SELECT_ICSC ;
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c +1 -1
@@ -1936,7 +1936,7 @@ static void update_dpp(struct dpp *dpp, struct dc_plane_state *plane_state) plane_state->format,EXPANSION_MODE_ZERO , plane_state->input_csc_color_matrix, - COLOR_SPACE_YCBCR601_LIMITED); + plane_state->color_space);//set scale and bias registers build_prescale_params (&bns_params, plane_state);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 117/155 ALSA: seq: Protect in-kernel ioctl calls with mutex
In reply to Greg Kroah-Hartman[ Upstream commit feb689025fbb6f0aa6297d3ddf97de945ea4ad32 ]
ALSA OSS sequencer calls the ioctl function indirectly via snd_seq_kernel_client_ctl(). While we already applied the protection against races between the normal ioctls and writes via the client's ioctl_mutex, this code path was left untouched. And this seems to be the cause of still remaining some rare UAF as spontaneously triggered by syzkaller.
For the sake of robustness, wrap the ioctl_mutex also for the call via snd_seq_kernel_client_ctl(), too.
--- sound/core/seq/seq_clientmgr.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
sound/core/seq/seq_clientmgr.c +7 -2
@@ -2343,14 +2343,19 @@ int snd_seq_kernel_client_ctl(int clientid, unsigned int cmd, void *arg) {const struct ioctl_handler *handler;struct snd_seq_client *client; +int err; client =clientptr (clientid);if (client ==NULL )return -ENXIO ;for (handler = ioctl_handlers; handler->cmd >0 ; ++handler) { -if (handler->cmd == cmd) -return handler->func (client, arg); +if (handler->cmd == cmd) { +mutex_lock (&client->ioctl_mutex); + err = handler->func (client, arg); +mutex_unlock (&client->ioctl_mutex); +return err; + } } pr_debug("ALSA: seq unknown ioctl() 0x%x (type='%c', number=0x%02x)\n",
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 118/155 ARM: OMAP2+: pm33xx-core: Do not Turn OFF CEFUSE as PPA may be using it
In reply to Greg Kroah-Hartman[ Upstream commit 72aff4ecf1cb85a3c6e6b42ccbda0bc631b090b3 ]
This area is used to store keys by HSPPA in case of AM438x SOC. Leave it active.
--- arch/arm/mach-omap2/pm33xx-core.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
arch/arm/mach-omap2/pm33xx-core.c +5 -3
@@ -51,10 +51,12 @@ static int amx3_common_init(void)/* CEFUSE domain can be turned off post bootup */ cefuse_pwrdm =pwrdm_lookup ("cefuse_pwrdm" ); -if (cefuse_pwrdm) -omap_set_pwrdm_state (cefuse_pwrdm,PWRDM_POWER_OFF ); -else +if (!cefuse_pwrdm)pr_err ("PM: Failed to get cefuse_pwrdm\n" ); +else if (omap_type () !=OMAP2_DEVICE_TYPE_GP ) +pr_info ("PM: Leaving EFUSE power domain active\n" ); +else +omap_set_pwrdm_state (cefuse_pwrdm,PWRDM_POWER_OFF );return 0 ; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 119/155 pinctrl: pinctrl-intel: move gpio suspend/resume to noirq phase
In reply to Greg Kroah-Hartman[ Upstream commit 2fef32766861c6e171f436ab99c89198cf0ca6e1 ]
In current driver, SET_LATE_SYSTEM_SLEEP_PM_OPS is used to install the callbacks for suspend/resume.
GPIO pin may be used as the interrupt pin by some device. However, using SET_LATE_SYSTEM_SLEEP_PM_OPS() to install the callbacks, the resume callback is called after resume_device_irqs(). Unintended interrupts may arrive due to resuming device irqs first, but the GPIO controller is not properly restored.
Normally, for a SMP system, there are multiple cores, so even when there are unintended interrupts, BSP gets the chance to initialize the GPIO chip soon. But when there is only 1 core is active (other cores are offlined or single core) during resume, it is more easily to observe the unintended interrupts.
This patch renames the suspend/resume function by adding suffix "_noirq", and installs the callbacks using SET_NOIRQ_SYSTEM_SLEEP_PM_OPS().
--- drivers/pinctrl/intel/pinctrl-intel.c | 8 ++++---- drivers/pinctrl/intel/pinctrl-intel.h | 11 ++++++----- 2 files changed, 10 insertions(+), 9 deletions(-)
drivers/pinctrl/intel/pinctrl-intel.c +4 -4
@@ -1466,7 +1466,7 @@ static bool intel_pinctrl_should_save(struct intel_pinctrl *pctrl, unsigned intreturn false; } -int intel_pinctrl_suspend (struct device *dev) +int intel_pinctrl_suspend_noirq (struct device *dev) {struct intel_pinctrl *pctrl =dev_get_drvdata (dev);struct intel_community_context *communities;
@@ -1505,7 +1505,7 @@ int intel_pinctrl_suspend(struct device *dev)return 0 ; } -EXPORT_SYMBOL_GPL (intel_pinctrl_suspend); +EXPORT_SYMBOL_GPL (intel_pinctrl_suspend_noirq);static void intel_gpio_irq_init (struct intel_pinctrl *pctrl) {
@@ -1527,7 +1527,7 @@ static void intel_gpio_irq_init(struct intel_pinctrl *pctrl) } } -int intel_pinctrl_resume (struct device *dev) +int intel_pinctrl_resume_noirq (struct device *dev) {struct intel_pinctrl *pctrl =dev_get_drvdata (dev);const struct intel_community_context *communities;
@@ -1589,7 +1589,7 @@ int intel_pinctrl_resume(struct device *dev) return 0; } -EXPORT_SYMBOL_GPL (intel_pinctrl_resume); +EXPORT_SYMBOL_GPL (intel_pinctrl_resume_noirq);#endif MODULE_AUTHOR ("Mathias Nyman <[email protected]>" );
drivers/pinctrl/intel/pinctrl-intel.h +6 -5
@@ -177,13 +177,14 @@ int intel_pinctrl_probe_by_hid(struct platform_device *pdev);int intel_pinctrl_probe_by_uid (struct platform_device *pdev);#ifdef CONFIG_PM_SLEEP -int intel_pinctrl_suspend (struct device *dev); -int intel_pinctrl_resume (struct device *dev); +int intel_pinctrl_suspend_noirq (struct device *dev); +int intel_pinctrl_resume_noirq (struct device *dev);#endif -#define INTEL_PINCTRL_PM_OPS (_name) \ -const struct dev_pm_ops _name = { \ - SET_LATE_SYSTEM_SLEEP_PM_OPS(intel_pinctrl_suspend, intel_pinctrl_resume) \ +#define INTEL_PINCTRL_PM_OPS (_name) \ +const struct dev_pm_ops _name = { \ + SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(intel_pinctrl_suspend_noirq, \ + intel_pinctrl_resume_noirq) \ }#endif /* PINCTRL_INTEL_H */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 120/155 platform/x86: intel_pmc_ipc: adding error handling
In reply to Greg Kroah-Hartman[ Upstream commit e61985d0550df8c2078310202aaad9b41049c36c ]
If punit or telemetry device initialization fails, pmc driver should unregister and return failure.
This change is to fix a kernel panic when removing kernel module intel_pmc_ipc.
--- drivers/platform/x86/intel_pmc_ipc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/platform/x86/intel_pmc_ipc.c +5 -1
@@ -771,13 +771,17 @@ static int ipc_create_pmc_devices(void)if (ret) {dev_err (ipcdev.dev,"Failed to add punit platform device\n" );platform_device_unregister (ipcdev.tco_dev); +return ret; }if (!ipcdev.telem_res_inval) { ret =ipc_create_telemetry_device (); -if (ret) +if (ret) {dev_warn (ipcdev.dev,"Failed to add telemetry platform device\n" ); +platform_device_unregister (ipcdev.punit_dev); +platform_device_unregister (ipcdev.tco_dev); + } }return ret;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 121/155 power: supply: max14656: fix potential use-before-alloc
In reply to Greg Kroah-Hartman[ Upstream commit 0cd0e49711556d2331a06b1117b68dd786cb54d2 ]
Call order on probe():
- max14656_hw_init() enables interrupts on the chip
- devm_request_irq() starts processing interrupts, isr could be called immediately
- isr: schedules delayed work (irq_work)
- irq_work: calls power_supply_changed()
- devm_power_supply_register() registers the power supply
Depending on timing, it's possible that power_supply_changed() is called on an unregistered power supply structure.
Fix by registering the power supply before requesting the irq.
--- drivers/power/supply/max14656_charger_detector.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
drivers/power/supply/max14656_charger_detector.c +7 -7
@@ -280,6 +280,13 @@ static int max14656_probe(struct i2c_client *client,INIT_DELAYED_WORK (&chip->irq_work, max14656_irq_worker); + chip->detect_psy =devm_power_supply_register (dev, + &chip->psy_desc, &psy_cfg); +if (IS_ERR (chip->detect_psy)) { +dev_err (dev,"power_supply_register failed\n" ); +return -EINVAL ; + } + ret =devm_request_irq (dev, chip->irq, max14656_irq,IRQF_TRIGGER_FALLING ,MAX14656_NAME , chip);
@@ -289,13 +296,6 @@ static int max14656_probe(struct i2c_client *client, }enable_irq_wake (chip->irq); - chip->detect_psy =devm_power_supply_register (dev, - &chip->psy_desc, &psy_cfg); -if (IS_ERR (chip->detect_psy)) { -dev_err (dev,"power_supply_register failed\n" ); -return -EINVAL ; - } -schedule_delayed_work (&chip->irq_work,msecs_to_jiffies (2000 ));return 0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 122/155 f2fs: fix potential recursive call when enabling data_flush
In reply to Greg Kroah-Hartman[ Upstream commit 186857c5a14aee85cace2ae7a36c6e43b9d3c7a5 ]
As Hagbard Celine reported:
Hi, this is a long standing bug that I've hit before on older kernels,
but I was not able to get the syslog saved because of the nature of
the bug. This time I had booted form a pen-drive, and was able to save
the log to it's efi-partition.
What i did to trigger it was to create a partition and format it f2fs,
then mount it with options:
"rw,relatime,lazytime,background_gc=on,disable_ext_identify,discard,heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,data_flush,extent_cache,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict". Then I unpacked a big .tar.xz to the partition (I used a
gentoo-stage3-tarball as I was in process of installing Gentoo).
Same options just without data_flush gives no problems.
Mar 20 20:54:01 usbgentoo kernel: FAT-fs (nvme0n1p4): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. Mar 20 21:05:23 usbgentoo kernel: kworker/dying (1588) used greatest stack depth: 12064 bytes left Mar 20 21:06:40 usbgentoo kernel: BUG: stack guard page was hit at 00000000a4b0733c (stack is 0000000056016422..0000000096e7463f) Mar 20 21:06:40 usbgentoo kernel: kernel stack overflow
......
Mar 20 21:06:40 usbgentoo kernel: Call Trace: Mar 20 21:06:40 usbgentoo kernel: read_node_page+0x71/0xf0 Mar 20 21:06:40 usbgentoo kernel: ? xas_load+0x8/0x50 Mar 20 21:06:40 usbgentoo kernel: __get_node_page+0x73/0x2a0 Mar 20 21:06:40 usbgentoo kernel: f2fs_get_dnode_of_data+0x34e/0x580 Mar 20 21:06:40 usbgentoo kernel: f2fs_write_inline_data+0x5e/0x2a0 Mar 20 21:06:40 usbgentoo kernel: __write_data_page+0x421/0x690 Mar 20 21:06:40 usbgentoo kernel: f2fs_write_cache_pages+0x1cf/0x460 Mar 20 21:06:40 usbgentoo kernel: f2fs_write_data_pages+0x2b3/0x2e0 Mar 20 21:06:40 usbgentoo kernel: ? f2fs_inode_chksum_verify+0x1d/0xc0 Mar 20 21:06:40 usbgentoo kernel: ? read_node_page+0x71/0xf0 Mar 20 21:06:40 usbgentoo kernel: do_writepages+0x3c/0xd0 Mar 20 21:06:40 usbgentoo kernel: __filemap_fdatawrite_range+0x7c/0xb0 Mar 20 21:06:40 usbgentoo kernel: f2fs_sync_dirty_inodes+0xf2/0x200 Mar 20 21:06:40 usbgentoo kernel: f2fs_balance_fs_bg+0x2a3/0x2c0 Mar 20 21:06:40 usbgentoo kernel: ? f2fs_inode_dirtied+0x21/0xc0 Mar 20 21:06:40 usbgentoo kernel: f2fs_balance_fs+0xd6/0x2b0 Mar 20 21:06:40 usbgentoo kernel: __write_data_page+0x4fb/0x690
......
Mar 20 21:06:40 usbgentoo kernel: __writeback_single_inode+0x2a1/0x340 Mar 20 21:06:40 usbgentoo kernel: ? soft_cursor+0x1b4/0x220 Mar 20 21:06:40 usbgentoo kernel: writeback_sb_inodes+0x1d5/0x3e0 Mar 20 21:06:40 usbgentoo kernel: __writeback_inodes_wb+0x58/0xa0 Mar 20 21:06:40 usbgentoo kernel: wb_writeback+0x250/0x2e0 Mar 20 21:06:40 usbgentoo kernel: ? 0xffffffff8c000000 Mar 20 21:06:40 usbgentoo kernel: ? cpumask_next+0x16/0x20 Mar 20 21:06:40 usbgentoo kernel: wb_workfn+0x2f6/0x3b0 Mar 20 21:06:40 usbgentoo kernel: ? __switch_to_asm+0x40/0x70 Mar 20 21:06:40 usbgentoo kernel: process_one_work+0x1f5/0x3f0 Mar 20 21:06:40 usbgentoo kernel: worker_thread+0x28/0x3c0 Mar 20 21:06:40 usbgentoo kernel: ? rescuer_thread+0x330/0x330 Mar 20 21:06:40 usbgentoo kernel: kthread+0x10e/0x130 Mar 20 21:06:40 usbgentoo kernel: ? kthread_create_on_node+0x60/0x60 Mar 20 21:06:40 usbgentoo kernel: ret_from_fork+0x35/0x40
The root cause is that we run into an infinite recursive calling in between f2fs_balance_fs_bg and writepage() as described below:
- f2fs_write_data_pages --- A
- __write_data_page
- f2fs_balance_fs
- f2fs_balance_fs_bg --- B
- f2fs_sync_dirty_inodes
- filemap_fdatawrite
- f2fs_write_data_pages --- A
...
- f2fs_balance_fs_bg --- B
...
In order to fix this issue, let's detect such condition in __write_data_page() and just skip calling f2fs_balance_fs() recursively.
--- fs/f2fs/checkpoint.c | 6 ++---- fs/f2fs/data.c | 3 ++- 2 files changed, 4 insertions(+), 5 deletions(-)
fs/f2fs/checkpoint.c +2 -4
@@ -1009,13 +1009,11 @@ retry:if (inode) {unsigned long cur_ino = inode->i_ino; -if (is_dir) -F2FS_I (inode)->cp_task = current; +F2FS_I (inode)->cp_task = current;filemap_fdatawrite (inode->i_mapping); -if (is_dir) -F2FS_I (inode)->cp_task =NULL ; +F2FS_I (inode)->cp_task =NULL ;iput (inode);/* We need to give cpu to another writers. */
fs/f2fs/data.c +2 -1
@@ -2038,7 +2038,8 @@ out: }unlock_page (page); -if (!S_ISDIR (inode->i_mode) && !IS_NOQUOTA (inode)) +if (!S_ISDIR (inode->i_mode) && !IS_NOQUOTA (inode) && + !F2FS_I (inode)->cp_task)f2fs_balance_fs (sbi, need_balance_fs);if (unlikely (f2fs_cp_error (sbi))) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 123/155 net: hns3: return 0 and print warning when hit duplicate MAC
In reply to Greg Kroah-Hartman[ Upstream commit 72110b567479f0282489a9b3747e76d8c67d75f5 ]
When set 2 same MAC to different function of one port, IMP will return error as the later one may modify the origin one. This will cause bond fail for 2 VFs of one port.
Driver just print warning and return 0 with this patch, so if set same MAC address, it will return 0 but do not really configure HW.
--- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +5 -2
@@ -5942,8 +5942,11 @@ int hclge_add_uc_addr_common(struct hclge_vport *vport, }/* check if we just hit the duplicate */ -if (!ret) - ret = -EINVAL ; +if (!ret) { +dev_warn (&hdev->pdev->dev,"VF %d mac(%pM) exists\n" , + vport->vport_id, addr); +return 0 ; + } dev_err(&hdev->pdev->dev, "PF failed to add unicast entry(%pM) in the MAC table\n",
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 124/155 PCI: dwc: Remove default MSI initialization for platform specific MSI chips
In reply to Greg Kroah-Hartman[ Upstream commit fd8a44bd5b76dc77133f814dd63d414d49dc74c0 ]
Platforms which populate msi_host_init() have their own MSI controller logic. Writing to MSI control registers on platforms which do not use Designware's MSI controller logic might have side effects.
To be safe, do not write to MSI control registers if the platform uses its own MSI controller logic instead of Designware's MSI one.
--- .../pci/controller/dwc/pcie-designware-host.c | 24 ++++++++++--------- 1 file changed, 13 insertions(+), 11 deletions(-)
drivers/pci/controller/dwc/pcie-designware-host.c +13 -11
@@ -653,17 +653,19 @@ void dw_pcie_setup_rc(struct pcie_port *pp)dw_pcie_setup (pci); - num_ctrls = pp->num_vectors /MAX_MSI_IRQS_PER_CTRL ; - -/* Initialize IRQ Status array */ -for (ctrl =0 ; ctrl < num_ctrls; ctrl++) { - pp->irq_mask[ctrl] = ~0 ; -dw_pcie_wr_own_conf (pp,PCIE_MSI_INTR0_MASK + - (ctrl *MSI_REG_CTRL_BLOCK_SIZE ), -4 , pp->irq_mask[ctrl]); -dw_pcie_wr_own_conf (pp,PCIE_MSI_INTR0_ENABLE + - (ctrl *MSI_REG_CTRL_BLOCK_SIZE ), -4 , ~0 ); +if (!pp->ops->msi_host_init) { + num_ctrls = pp->num_vectors /MAX_MSI_IRQS_PER_CTRL ; + +/* Initialize IRQ Status array */ +for (ctrl =0 ; ctrl < num_ctrls; ctrl++) { + pp->irq_mask[ctrl] = ~0 ; +dw_pcie_wr_own_conf (pp,PCIE_MSI_INTR0_MASK + + (ctrl *MSI_REG_CTRL_BLOCK_SIZE ), +4 , pp->irq_mask[ctrl]); +dw_pcie_wr_own_conf (pp,PCIE_MSI_INTR0_ENABLE + + (ctrl *MSI_REG_CTRL_BLOCK_SIZE ), +4 , ~0 ); + } }/* Setup RC BARs */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 125/155 PCI: rcar: Fix a potential NULL pointer dereference
In reply to Greg Kroah-Hartman[ Upstream commit f0d14edd2ba43b995bef4dd5da5ffe0ae19321a1 ]
In case __get_free_pages() fails and returns NULL, fix the return value to -ENOMEM and release resources to avoid dereferencing a NULL pointer.
--- drivers/pci/controller/pcie-rcar.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/pci/controller/pcie-rcar.c +4 -0
@@ -931,6 +931,10 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)/* setup MSI data target */ msi->pages =__get_free_pages (GFP_KERNEL ,0 ); +if (!msi->pages) { + err = -ENOMEM ; + goto err; + } base =virt_to_phys ((void *)msi->pages);rcar_pci_write_reg (pcie, base |MSIFE ,PCIEMSIALR );
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 126/155 PCI: rcar: Fix 64bit MSI message address handling
In reply to Greg Kroah-Hartman[ Upstream commit 954b4b752a4c4e963b017ed8cef4c453c5ed308d ]
The MSI message address in the RC address space can be 64 bit. The R-Car PCIe RC supports such a 64bit MSI message address as well. The code currently uses virt_to_phys(__get_free_pages()) to obtain a reserved page for the MSI message address, and the return value of which can be a 64 bit physical address on 64 bit system.
However, the driver only programs PCIEMSIALR register with the bottom 32 bits of the virt_to_phys(__get_free_pages()) return value and does not program the top 32 bits into PCIEMSIAUR, but rather programs the PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car SoCs, however may fail on new 64 bit R-Car SoCs.
Since from a PCIe controller perspective, an inbound MSI is a memory write to a special address (in case of this controller, defined by the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but never hits the DRAM _and_ because allocation of an MSI by a PCIe card driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot cause memory corruption or other issues.
There is however the possibility that if virt_to_phys(__get_free_pages()) returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed to 0x0 _and_ if the system had physical RAM at the address matching the value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a physical address matching the value of PCIEMSIALR and a remote write to such a buffer by a PCIe card would trigger a spurious MSI.
--- drivers/pci/controller/pcie-rcar.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/pci/controller/pcie-rcar.c +3 -3
@@ -892,7 +892,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie) {struct device *dev = pcie->dev;struct rcar_msi *msi = &pcie->msi; -unsigned long base; +phys_addr_t base;int err, i;mutex_init (&msi->lock);
@@ -937,8 +937,8 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie) } base =virt_to_phys ((void *)msi->pages); -rcar_pci_write_reg (pcie, base |MSIFE ,PCIEMSIALR ); -rcar_pci_write_reg (pcie,0 ,PCIEMSIAUR ); +rcar_pci_write_reg (pcie,lower_32_bits (base) |MSIFE ,PCIEMSIALR ); +rcar_pci_write_reg (pcie,upper_32_bits (base),PCIEMSIAUR );/* enable all MSI interrupts */ rcar_pci_write_reg (pcie,0xffffffff ,PCIEMSIIER );
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 127/155 scsi: qla2xxx: Reset the FCF_ASYNC_{SENT|ACTIVE} flags
In reply to Greg Kroah-Hartman[ Upstream commit 0257eda08e806b82ee1fc90ef73583b6f022845c ]
Driver maintains state machine for processing and completing switch commands. This patch resets FCF_ASYNC_{SENT|ACTIVE} flag to indicate if the previous command is active or sent, in order for next GPSC command to advance the state machine.
[mkp: commit desc typo]
--- drivers/scsi/qla2xxx/qla_gs.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/scsi/qla2xxx/qla_gs.c +3 -0
@@ -3031,6 +3031,8 @@ static void qla24xx_async_gpsc_sp_done(void *s, int res)"Async done-%s res %x, WWPN %8phC \n" , sp->name, res, fcport->port_name); + fcport->flags &= ~(FCF_ASYNC_SENT |FCF_ASYNC_ACTIVE ); +if (res ==QLA_FUNCTION_TIMEOUT )return ;
@@ -4370,6 +4372,7 @@ int qla24xx_async_gnnid(scsi_qla_host_t *vha, fc_port_t *fcport) done_free_sp: sp->free (sp); + fcport->flags &= ~FCF_ASYNC_SENT ; done:return rval; }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 128/155 Input: goodix - add GT5663 CTP support
In reply to Greg Kroah-Hartman[ Upstream commit a5f50c501321249d67611353dde6d68d48c5b959 ]
GT5663 is capacitive touch controller with customized smart wakeup gestures.
Add support for it by adding compatible and supported chip data.
The chip data on GT5663 is similar to GT1151, like
- config data register has 0x8050 address
- config data register max len is 240
- config data checksum has 16-bit
--- Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 1 + drivers/input/touchscreen/goodix.c | 2 ++ 2 files changed, 3 insertions(+)
Documentation/devicetree/bindings/input/touchscreen/goodix.txt +1 -0
@@ -3,6 +3,7 @@ Device tree bindings for Goodix GT9xx series touchscreen controller Required properties: - compatible : Should be "goodix,gt1151" + or "goodix,gt5663" or "goodix,gt5688" or "goodix,gt911" or "goodix,gt9110"
drivers/input/touchscreen/goodix.c +2 -0
@@ -216,6 +216,7 @@ static const struct goodix_chip_data *goodix_get_chip_data(u16 id) {switch (id) {case 1151 : +case 5663 :case 5688 :return >1x_chip_data;
@@ -945,6 +946,7 @@ MODULE_DEVICE_TABLE(acpi, goodix_acpi_match);#ifdef CONFIG_OF static const struct of_device_id goodix_of_match[] = { { .compatible ="goodix,gt1151" }, + { .compatible ="goodix,gt5663" }, { .compatible ="goodix,gt5688" }, { .compatible ="goodix,gt911" }, { .compatible = "goodix,gt9110" },
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 129/155 video: hgafb: fix potential NULL pointer dereference
In reply to Greg Kroah-Hartman[ Upstream commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542 ]
When ioremap fails, hga_vram should not be dereferenced. The fix check the failure to avoid NULL pointer dereference.
--- drivers/video/fbdev/hgafb.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/video/fbdev/hgafb.c +2 -0
@@ -285,6 +285,8 @@ static int hga_card_detect(void) hga_vram_len =0x08000 ; hga_vram =ioremap (0xb0000 , hga_vram_len); +if (!hga_vram) + goto error;if (request_region (0x3b0 ,12 ,"hgafb" )) release_io_ports =1 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 130/155 video: imsttfb: fix potential NULL pointer dereferences
In reply to Greg Kroah-Hartman[ Upstream commit 1d84353d205a953e2381044953b7fa31c8c9702d ]
In case ioremap fails, the fix releases resources and returns -ENOMEM to avoid NULL pointer dereferences.
--- drivers/video/fbdev/imsttfb.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/video/fbdev/imsttfb.c +5 -0
@@ -1515,6 +1515,11 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) info->fix.smem_start = addr; info->screen_base = (__u8 *)ioremap (addr, par->ramdac ==IBM ?0x400000 :0x800000 ); +if (!info->screen_base) { +release_mem_region (addr, size); +framebuffer_release (info); +return -ENOMEM ; + } info->fix.mmio_start = addr +0x800000 ; par->dc_regs =ioremap (addr +0x800000 ,0x1000 ); par->cmap_regs_phys = addr +0x840000 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 131/155 block, bfq: increase idling for weight-raised queues
In reply to Greg Kroah-Hartman[ Upstream commit 778c02a236a8728bb992de10ed1f12c0be5b7b0e ]
If a sync bfq_queue has a higher weight than some other queue, and remains temporarily empty while in service, then, to preserve the bandwidth share of the queue, it is necessary to plug I/O dispatching until a new request arrives for the queue. In addition, a timeout needs to be set, to avoid waiting for ever if the process associated with the queue has actually finished its I/O.
Even with the above timeout, the device is however not fed with new I/O for a while, if the process has finished its I/O. If this happens often, then throughput drops and latencies grow. For this reason, the timeout is kept rather low: 8 ms is the current default.
Unfortunately, such a low value may cause, on the opposite end, a violation of bandwidth guarantees for a process that happens to issue new I/O too late. The higher the system load, the higher the probability that this happens to some process. This is a problem in scenarios where service guarantees matter more than throughput. One important case are weight-raised queues, which need to be granted a very high fraction of the bandwidth.
To address this issue, this commit lower-bounds the plugging timeout for weight-raised queues to 20 ms. This simple change provides relevant benefits. For example, on a PLEXTOR PX-256M5S, with which gnome-terminal starts in 0.6 seconds if there is no other I/O in progress, the same applications starts in
- 0.8 seconds, instead of 1.2 seconds, if ten files are being read sequentially in parallel
- 1 second, instead of 2 seconds, if, in parallel, five files are being read sequentially, and five more files are being written sequentially
--- block/bfq-iosched.c | 2 ++ 1 file changed, 2 insertions(+)
block/bfq-iosched.c +2 -0
@@ -2545,6 +2545,8 @@ static void bfq_arm_slice_timer(struct bfq_data *bfqd)if (BFQQ_SEEKY (bfqq) && bfqq->wr_coeff ==1 &&bfq_symmetric_scenario (bfqd)) sl =min_t (u64, sl,BFQ_MIN_TT ); +else if (bfqq->wr_coeff >1 ) + sl =max_t (u32, sl,20ULL *NSEC_PER_MSEC ); bfqd->last_idling_start =ktime_get (); hrtimer_start(&bfqd->idle_slice_timer, ns_to_ktime(sl),
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 132/155 PCI: xilinx: Check for __get_free_pages() failure
In reply to Greg Kroah-Hartman[ Upstream commit 699ca30162686bf305cdf94861be02eb0cf9bda2 ]
If __get_free_pages() fails, return -ENOMEM to avoid a NULL pointer dereference.
--- drivers/pci/controller/pcie-xilinx.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/pci/controller/pcie-xilinx.c +10 -2
@@ -336,14 +336,19 @@ static const struct irq_domain_ops msi_domain_ops = {* xilinx_pcie_enable_msi - Enable MSI support * @port: PCIe port information */ -static void xilinx_pcie_enable_msi (struct xilinx_pcie_port *port) +static int xilinx_pcie_enable_msi (struct xilinx_pcie_port *port) {phys_addr_t msg_addr; port->msi_pages =__get_free_pages (GFP_KERNEL ,0 ); +if (!port->msi_pages) +return -ENOMEM ; + msg_addr =virt_to_phys ((void *)port->msi_pages);pcie_write (port,0x0 ,XILINX_PCIE_REG_MSIBASE1 );pcie_write (port, msg_addr,XILINX_PCIE_REG_MSIBASE2 ); + +return 0 ; }/* INTx Functions */
@@ -498,6 +503,7 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)struct device *dev = port->dev;struct device_node *node = dev->of_node;struct device_node *pcie_intc_node; +int ret;/* Setup INTx */ pcie_intc_node =of_get_next_child (node,NULL );
@@ -526,7 +532,9 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)return -ENODEV ; } -xilinx_pcie_enable_msi (port); + ret =xilinx_pcie_enable_msi (port); +if (ret) +return ret; }return 0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 133/155 arm64: dts: qcom: qcs404: Fix regulator supply names
In reply to Greg Kroah-Hartman[ Upstream commit f95f57e4372207ede83ac28f300aba719b271ed5 ]
The regulator definition got their supply names cleaned up during upstreaming, so they no longer match the driver defined names. Update the supply names.
Also fill out the missing voltage of SMPS 5.
--- arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 28 ++++++++++++------------ 1 file changed, 14 insertions(+), 14 deletions(-)
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi +14 -14
@@ -37,18 +37,18 @@ pms405-regulators { compatible = "qcom,rpm-pms405-regulators"; - vdd-s1-supply = <&vph_pwr>; - vdd-s2-supply = <&vph_pwr>; - vdd-s3-supply = <&vph_pwr>; - vdd-s4-supply = <&vph_pwr>; - vdd-s5-supply = <&vph_pwr>; - vdd-l1-l2-supply = <&vreg_s5_1p35>; - vdd-l3-l8-supply = <&vreg_s5_1p35>; - vdd-l4-supply = <&vreg_s5_1p35>; - vdd-l5-l6-supply = <&vreg_s4_1p8>; - vdd-l7-supply = <&vph_pwr>; - vdd-l9-supply = <&vreg_s5_1p35>; - vdd-l10-l11-l12-l13-supply = <&vph_pwr>; + vdd_s1-supply = <&vph_pwr>; + vdd_s2-supply = <&vph_pwr>; + vdd_s3-supply = <&vph_pwr>; + vdd_s4-supply = <&vph_pwr>; + vdd_s5-supply = <&vph_pwr>; + vdd_l1_l2-supply = <&vreg_s5_1p35>; + vdd_l3_l8-supply = <&vreg_s5_1p35>; + vdd_l4-supply = <&vreg_s5_1p35>; + vdd_l5_l6-supply = <&vreg_s4_1p8>; + vdd_l7-supply = <&vph_pwr>; + vdd_l9-supply = <&vreg_s5_1p35>; + vdd_l10_l11_l12_l13-supply = <&vph_pwr>; vreg_s4_1p8: s4 { regulator-min-microvolt = <1728000>;
@@ -56,8 +56,8 @@ }; vreg_s5_1p35: s5 { - regulator-min-microvolt = <>; - regulator-max-microvolt = <>; + regulator-min-microvolt = <1352000>; + regulator-max-microvolt = <1352000>; }; vreg_l1_1p3: l1 {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 134/155 gpio: gpio-omap: add check for off wake capable gpios
In reply to Greg Kroah-Hartman[ Upstream commit da38ef3ed10a09248e13ae16530c2c6d448dc47d ]
We are currently assuming all GPIOs are non-wakeup capable GPIOs as we not configuring the bank->non_wakeup_gpios like we used to earlier with platform_data.
Let's add omap_gpio_is_off_wakeup_capable() to make the handling clearer while considering that later patches may want to configure SoC specific bank->non_wakeup_gpios for the GPIOs in wakeup domain.
--- drivers/gpio/gpio-omap.c | 25 +++++++++++++++++-------- 1 file changed, 17 insertions(+), 8 deletions(-)
drivers/gpio/gpio-omap.c +17 -8
@@ -353,6 +353,22 @@ static void omap_clear_gpio_debounce(struct gpio_bank *bank, unsigned offset) } } +/* +* Off mode wake-up capable GPIOs in bank(s) that are in the wakeup domain. +* See TRM section for GPIO for "Wake-Up Generation" for the list of GPIOs +* in wakeup domain. If bank->non_wakeup_gpios is not configured, assume none +* are capable waking up the system from off mode. +*/ +static bool omap_gpio_is_off_wakeup_capable (struct gpio_bank *bank,u32 gpio_mask) +{ +u32 no_wake = bank->non_wakeup_gpios; + +if (no_wake) +return !!(~no_wake & gpio_mask); + +return false; +} +static inline void omap_set_gpio_trigger (struct gpio_bank *bank,int gpio,unsigned trigger) {
@@ -384,13 +400,7 @@ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio, }/* This part needs to be executed always for OMAP{34xx, 44xx} */ -if (!bank->regs->irqctrl) { -/* On omap24xx proceed only when valid GPIO bit is set */ -if (bank->non_wakeup_gpios) { -if (!(bank->non_wakeup_gpios & gpio_bit)) - goto exit; - } - +if (!bank->regs->irqctrl && !omap_gpio_is_off_wakeup_capable (bank, gpio)) {/* * Log the edge gpio and manually trigger the IRQ * after resume if the input level changes
@@ -403,7 +413,6 @@ static inline void omap_set_gpio_trigger(struct gpio_bank *bank, int gpio, bank->enabled_non_wakeup_gpios &= ~gpio_bit; } -exit: bank->level_mask =readl_relaxed (bank->base + bank->regs->leveldetect0) |readl_relaxed (bank->base + bank->regs->leveldetect1);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 135/155 gpio: gpio-omap: limit errata 1.101 handling to wkup domain gpios only
In reply to Greg Kroah-Hartman[ Upstream commit 21e2118f470302f16bee7ebd1444505eadbc2c20 ]
We need to only apply errata 1.101 handling to clear non-wakeup edge gpios for idle to the gpio bank(s) in the wkup domain to prevent spurious wake-up events.
And we must restore what we did after idle manually as the gpio bank in wkup domain is not restored otherwise.
Let's keep bank->saved_datain register reading separate, that's not related to the 1.101 errata and is used separately on restore.
--- drivers/gpio/gpio-omap.c | 28 ++++++++++++++++------------ 1 file changed, 16 insertions(+), 12 deletions(-)
drivers/gpio/gpio-omap.c +16 -12
@@ -1453,7 +1453,10 @@ static void omap_gpio_restore_context(struct gpio_bank *bank);static void omap_gpio_idle (struct gpio_bank *bank,bool may_lose_context) {struct device *dev = bank->chip.parent; -u32 l1 =0 , l2 =0 ; +void __iomem *base = bank->base; +u32 nowake; + + bank->saved_datain =readl_relaxed (base + bank->regs->datain);if (bank->funcs.idle_enable_level_quirk) bank->funcs.idle_enable_level_quirk (bank);
@@ -1465,20 +1468,15 @@ static void omap_gpio_idle(struct gpio_bank *bank, bool may_lose_context) goto update_gpio_context_count;/* -* If going to OFF, remove triggering for all +* If going to OFF, remove triggering for all wkup domain * non-wakeup GPIOs. Otherwise spurious IRQs will be * generated. See OMAP2420 Errata item 1.101. */ - bank->saved_datain =readl_relaxed (bank->base + - bank->regs->datain); - l1 = bank->context.fallingdetect; - l2 = bank->context.risingdetect; - - l1 &= ~bank->enabled_non_wakeup_gpios; - l2 &= ~bank->enabled_non_wakeup_gpios; - -writel_relaxed (l1, bank->base + bank->regs->fallingdetect); -writel_relaxed (l2, bank->base + bank->regs->risingdetect); +if (!bank->loses_context && bank->enabled_non_wakeup_gpios) { + nowake = bank->enabled_non_wakeup_gpios; +omap_gpio_rmw (base, bank->regs->fallingdetect, nowake, ~nowake); +omap_gpio_rmw (base, bank->regs->risingdetect, nowake, ~nowake); + } bank->workaround_enabled = true;
@@ -1527,6 +1525,12 @@ static void omap_gpio_unidle(struct gpio_bank *bank)return ; } } + }else { +/* Restore changes done for OMAP2420 errata 1.101 */ +writel_relaxed (bank->context.fallingdetect, + bank->base + bank->regs->fallingdetect); +writel_relaxed (bank->context.risingdetect, + bank->base + bank->regs->risingdetect); }if (!bank->workaround_enabled)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 136/155 ice: Add missing case in print_link_msg for printing flow control
In reply to Greg Kroah-Hartman[ Upstream commit 203a068ac9e2722e4d118116acaa3a5586f9468a ]
Currently we aren't checking for the ICE_FC_NONE case for the current flow control mode. This is causing "Unknown" to be printed for the current flow control method if flow control is disabled. Fix this by adding the case for ICE_FC_NONE to print "None".
--- drivers/net/ethernet/intel/ice/ice_main.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/intel/ice/ice_main.c +3 -0
@@ -528,6 +528,9 @@ void ice_print_link_msg(struct ice_vsi *vsi, bool isup)case ICE_FC_RX_PAUSE : fc ="RX" ;break ; +case ICE_FC_NONE : + fc ="None" ; +break ;default : fc ="Unknown" ;break ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 137/155 media: v4l2-ctrl: v4l2_ctrl_request_setup returns with error upon failure
In reply to Greg Kroah-Hartman[ Upstream commit 09ca38a50795a263d2b16dc95794dc5bc17c1d5c ]
If one of the controls fails to set,
then 'v4l2_ctrl_request_setup'
immediately returns with the error code.
--- drivers/media/v4l2-core/v4l2-ctrls.c | 18 +++++++++++------- include/media/v4l2-ctrls.h | 2 +- 2 files changed, 12 insertions(+), 8 deletions(-)
drivers/media/v4l2-core/v4l2-ctrls.c +11 -7
@@ -3899,18 +3899,19 @@ void v4l2_ctrl_request_complete(struct media_request *req, }EXPORT_SYMBOL (v4l2_ctrl_request_complete); -void v4l2_ctrl_request_setup (struct media_request *req, +int v4l2_ctrl_request_setup (struct media_request *req,struct v4l2_ctrl_handler *main_hdl) {struct media_request_object *obj;struct v4l2_ctrl_handler *hdl;struct v4l2_ctrl_ref *ref; +int ret =0 ;if (!req || !main_hdl) -return ; +return 0 ;if (WARN_ON (req->state !=MEDIA_REQUEST_STATE_QUEUED )) -return ; +return -EBUSY ;/* * Note that it is valid if nothing was found. It means
@@ -3919,10 +3920,10 @@ void v4l2_ctrl_request_setup(struct media_request *req,*/ obj =media_request_object_find (req, &req_ops, main_hdl);if (!obj) -return ; +return 0 ;if (obj->completed) {media_request_object_put (obj); -return ; +return -EBUSY ; } hdl = container_of(obj, struct v4l2_ctrl_handler, req_obj);
@@ -3990,12 +3991,15 @@ void v4l2_ctrl_request_setup(struct media_request *req,update_from_auto_cluster (master); } -try_or_set_cluster (NULL , master, true,0 ); - + ret =try_or_set_cluster (NULL , master, true,0 );v4l2_ctrl_unlock (master); + +if (ret) +break ; }media_request_object_put (obj); +return ret; }EXPORT_SYMBOL (v4l2_ctrl_request_setup);
include/media/v4l2-ctrls.h +1 -1
@@ -1127,7 +1127,7 @@ __poll_t v4l2_ctrl_poll(struct file *file, struct poll_table_struct *wait);* applying control values in a request is only applicable to memory-to-memory * devices. */ -void v4l2_ctrl_request_setup (struct media_request *req, +int v4l2_ctrl_request_setup (struct media_request *req,struct v4l2_ctrl_handler *parent);/**
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 138/155 batman-adv: Adjust name for batadv_dat_send_data
In reply to Greg Kroah-Hartman[ Upstream commit c2d8b9a6c17a3848136b3eb31f26d3c5880acd89 ]
The send functions in batman-adv are expected to consume the skb when either the data is queued up for the underlying driver or when some precondition failed. batadv_dat_send_data didn't do this and instead created a copy of the skb, modified it and queued the copy up for transmission. The caller has to take care that the skb is handled correctly (for example free'd) when batadv_dat_send_data returns.
This unclear behavior already lead to memory leaks in the recent past. Renaming the function to batadv_dat_forward_data should make it easier to identify that the data is forwarded but the skb is not actually send+consumed.
--- net/batman-adv/distributed-arp-table.c | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-)
net/batman-adv/distributed-arp-table.c +14 -10
@@ -667,7 +667,7 @@ batadv_dat_select_candidates(struct batadv_priv *bat_priv, __be32 ip_dst, }/** -* batadv_dat_send_data() - send a payload to the selected candidates +* batadv_dat_forward_data() - copy and send payload to the selected candidates * @bat_priv: the bat priv with all the soft interface information * @skb: payload to send * @ip: the DHT key
@@ -680,9 +680,9 @@ batadv_dat_select_candidates(struct batadv_priv *bat_priv, __be32 ip_dst,* Return: true if the packet is sent to at least one candidate, false * otherwise. */ -static bool batadv_dat_send_data (struct batadv_priv *bat_priv, -struct sk_buff *skb,__be32 ip, -unsigned short vid,int packet_subtype) +static bool batadv_dat_forward_data (struct batadv_priv *bat_priv, +struct sk_buff *skb,__be32 ip, +unsigned short vid,int packet_subtype) {int i;bool ret = false;
@@ -1277,8 +1277,8 @@ bool batadv_dat_snoop_outgoing_arp_request(struct batadv_priv *bat_priv, ret = true; }else {/* Send the request to the DHT */ - ret =batadv_dat_send_data (bat_priv, skb, ip_dst, vid, -BATADV_P_DAT_DHT_GET ); + ret =batadv_dat_forward_data (bat_priv, skb, ip_dst, vid, +BATADV_P_DAT_DHT_GET ); } out:if (dat_entry)
@@ -1392,8 +1392,10 @@ void batadv_dat_snoop_outgoing_arp_reply(struct batadv_priv *bat_priv,/* Send the ARP reply to the candidates for both the IP addresses that * the node obtained from the ARP reply */ -batadv_dat_send_data (bat_priv, skb, ip_src, vid,BATADV_P_DAT_DHT_PUT ); -batadv_dat_send_data (bat_priv, skb, ip_dst, vid,BATADV_P_DAT_DHT_PUT ); +batadv_dat_forward_data (bat_priv, skb, ip_src, vid, +BATADV_P_DAT_DHT_PUT ); +batadv_dat_forward_data (bat_priv, skb, ip_dst, vid, +BATADV_P_DAT_DHT_PUT ); }/**
@@ -1710,8 +1712,10 @@ static void batadv_dat_put_dhcp(struct batadv_priv *bat_priv, u8 *chaddr,batadv_dat_entry_add (bat_priv, yiaddr, chaddr, vid);batadv_dat_entry_add (bat_priv, ip_dst, hw_dst, vid); -batadv_dat_send_data (bat_priv, skb, yiaddr, vid,BATADV_P_DAT_DHT_PUT ); -batadv_dat_send_data (bat_priv, skb, ip_dst, vid,BATADV_P_DAT_DHT_PUT ); +batadv_dat_forward_data (bat_priv, skb, yiaddr, vid, +BATADV_P_DAT_DHT_PUT ); +batadv_dat_forward_data (bat_priv, skb, ip_dst, vid, +BATADV_P_DAT_DHT_PUT );consume_skb (skb);
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 139/155 ice: Enable LAN_EN for the right recipes
In reply to Greg Kroah-Hartman[ Upstream commit 277b3a4547b8afbbecdfc52fe7217f018de26c21 ]
In VEB mode, enable LAN_EN bit in the action fields for filter rules corresponding to the right recipes.
--- drivers/net/ethernet/intel/ice/ice_switch.c | 29 ++++++++++++++------- 1 file changed, 20 insertions(+), 9 deletions(-)
drivers/net/ethernet/intel/ice/ice_switch.c +20 -9
@@ -644,20 +644,31 @@ static void ice_fill_sw_info(struct ice_hw *hw, struct ice_fltr_info *fi) fi->fltr_act == ICE_FWD_TO_Q || fi->fltr_act == ICE_FWD_TO_QGRP)) { fi->lb_en = true; -/* Do not set lan_en to TRUE if +/* Set lan_en to TRUE if * 1. The switch is a VEB AND * 2 -* 2.1 The lookup is MAC with unicast addr for MAC, OR -* 2.2 The lookup is MAC_VLAN with unicast addr for MAC +* 2.1 The lookup is VLAN, OR +* 2.2 The lookup is default port mode, OR +* 2.3 The lookup is MAC with mcast or bcast addr for MAC, OR +* 2.4 The lookup is MAC_VLAN with mcast or bcast addr for MAC. * -* In all other cases, the LAN enable has to be set to true. +* OR +* +* The switch is a VEPA. +* +* In all other cases, the LAN enable has to be set to false. */ -if (!(hw->evb_veb && - ((fi->lkup_type ==ICE_SW_LKUP_MAC && -is_unicast_ether_addr (fi->l_data.mac.mac_addr)) || - (fi->lkup_type ==ICE_SW_LKUP_MAC_VLAN && -is_unicast_ether_addr (fi->l_data.mac_vlan.mac_addr))))) +if (hw->evb_veb) { +if (fi->lkup_type ==ICE_SW_LKUP_VLAN || + fi->lkup_type ==ICE_SW_LKUP_DFLT || + (fi->lkup_type ==ICE_SW_LKUP_MAC && + !is_unicast_ether_addr (fi->l_data.mac.mac_addr)) || + (fi->lkup_type ==ICE_SW_LKUP_MAC_VLAN && + !is_unicast_ether_addr (fi->l_data.mac.mac_addr))) + fi->lan_en = true; + }else { fi->lan_en = true; + } } }
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 140/155 ice: Do not set LB_EN for prune switch rules
In reply to Greg Kroah-Hartman[ Upstream commit b58dafbc6f1089942c1e74b8ab9c616fe06dbfac ]
LB_EN for prune switch rules was causing all TX traffic to loopback to the internal switch and dropped. When running bi-directional stress workloads with RDMA the RDPU would hang blocking tx and rx traffic.
--- drivers/net/ethernet/intel/ice/ice_switch.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/net/ethernet/intel/ice/ice_switch.c +6 -1
@@ -643,7 +643,12 @@ static void ice_fill_sw_info(struct ice_hw *hw, struct ice_fltr_info *fi) fi->fltr_act == ICE_FWD_TO_VSI_LIST || fi->fltr_act == ICE_FWD_TO_Q || fi->fltr_act == ICE_FWD_TO_QGRP)) { - fi->lb_en = true; +/* Setting LB for prune actions will result in replicated +* packets to the internal switch that will be dropped. +*/ +if (fi->lkup_type !=ICE_SW_LKUP_VLAN ) + fi->lb_en = true; +/* Set lan_en to TRUE if * 1. The switch is a VEB AND * 2
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 141/155 dmaengine: idma64: Use actual device for DMA transfers
In reply to Greg Kroah-Hartman[ Upstream commit 5ba846b1ee0792f5a596b9b0b86d6e8cdebfab06 ]
Intel IOMMU, when enabled, tries to find the domain of the device, assuming it's a PCI one, during DMA operations, such as mapping or unmapping. Since we are splitting the actual PCI device to couple of children via MFD framework (see drivers/mfd/intel-lpss.c for details), the DMA device appears to be a platform one, and thus not an actual one that performs DMA. In a such situation IOMMU can't find or allocate a proper domain for its operations. As a result, all DMA operations are failed.
In order to fix this, supply parent of the platform device to the DMA engine framework and fix filter functions accordingly.
We may rely on the fact that parent is a real PCI device, because no other configuration is present in the wild.
--- drivers/dma/idma64.c | 6 ++++-- drivers/dma/idma64.h | 2 ++ drivers/spi/spi-pxa2xx.c | 7 +------ drivers/tty/serial/8250/8250_dw.c | 4 ++-- 4 files changed, 9 insertions(+), 10 deletions(-)
drivers/dma/idma64.c +4 -2
@@ -592,7 +592,7 @@ static int idma64_probe(struct idma64_chip *chip) idma64->dma.directions =BIT (DMA_DEV_TO_MEM ) |BIT (DMA_MEM_TO_DEV ); idma64->dma.residue_granularity =DMA_RESIDUE_GRANULARITY_BURST ; - idma64->dma.dev = chip->dev; + idma64->dma.dev = chip->sysdev;dma_set_max_seg_size (idma64->dma.dev,IDMA64C_CTLH_BLOCK_TS_MASK );
@@ -632,6 +632,7 @@ static int idma64_platform_probe(struct platform_device *pdev) {struct idma64_chip *chip;struct device *dev = &pdev->dev; +struct device *sysdev = dev->parent;struct resource *mem;int ret;
@@ -648,11 +649,12 @@ static int idma64_platform_probe(struct platform_device *pdev)if (IS_ERR (chip->regs))return PTR_ERR (chip->regs); - ret =dma_coerce_mask_and_coherent (&pdev->dev,DMA_BIT_MASK (64 )); + ret =dma_coerce_mask_and_coherent (sysdev,DMA_BIT_MASK (64 ));if (ret)return ret; chip->dev = dev; + chip->sysdev = sysdev; ret =idma64_probe (chip);if (ret)
drivers/dma/idma64.h +2 -0
@@ -216,12 +216,14 @@ static inline void idma64_writel(struct idma64 *idma64, int offset, u32 value)/** * struct idma64_chip - representation of iDMA 64-bit controller hardware * @dev: struct device of the DMA controller +* @sysdev: struct device of the physical device that does DMA * @irq: irq line * @regs: memory mapped I/O space * @idma64: struct idma64 that is filed by idma64_probe() */ struct idma64_chip {struct device *dev; +struct device *sysdev;int irq;void __iomem *regs;struct idma64 *idma64;
drivers/spi/spi-pxa2xx.c +1 -6
@@ -1491,12 +1491,7 @@ static int pxa2xx_spi_get_port_id(struct acpi_device *adev)static bool pxa2xx_spi_idma_filter (struct dma_chan *chan,void *param) { -struct device *dev = param; - -if (dev != chan->device->dev->parent) -return false; - -return true; +return param == chan->device->dev; }#endif /* CONFIG_PCI */
drivers/tty/serial/8250/8250_dw.c +2 -2
@@ -365,7 +365,7 @@ static bool dw8250_fallback_dma_filter(struct dma_chan *chan, void *param)static bool dw8250_idma_filter (struct dma_chan *chan,void *param) { -return param == chan->device->dev->parent; +return param == chan->device->dev; }/*
@@ -434,7 +434,7 @@ static void dw8250_quirks(struct uart_port *p, struct dw8250_data *data) data->uart_16550_compatible = true; } -/* Platforms with iDMA */ +/* Platforms with iDMA 64-bit */ if (platform_get_resource_byname (to_platform_device (p->dev),IORESOURCE_MEM ,"lpss_priv" )) { data->dma.rx_param = p->dev->parent;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 142/155 pwm: tiehrpwm: Update shadow register for disabling PWMs
In reply to Greg Kroah-Hartman[ Upstream commit b00ef53053191d3025c15e8041699f8c9d132daf ]
It must be made sure that immediate mode is not already set, when modifying shadow register value in ehrpwm_pwm_disable(). Otherwise modifications to the action-qualifier continuous S/W force register(AQSFRC) will be done in the active register.
This may happen when both channels are being disabled. In this case, only the first channel state will be recorded as disabled in the shadow register. Later, when enabling the first channel again, the second channel would be enabled as well. Setting RLDCSF to zero, first, ensures that the shadow register is updated as desired.
--- drivers/pwm/pwm-tiehrpwm.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/pwm/pwm-tiehrpwm.c +2 -0
@@ -382,6 +382,8 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm) }/* Update shadow register first before modifying active register */ +ehrpwm_modify (pc->mmio_base,AQSFRC ,AQSFRC_RLDCSF_MASK , +AQSFRC_RLDCSF_ZRO );ehrpwm_modify (pc->mmio_base,AQCSFRC , aqcsfrc_mask, aqcsfrc_val);/* * Changes to immediate action on Action Qualifier. This puts
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 143/155 media: v4l2-fwnode: Defaults may not override endpoint configuration in firmware
In reply to Greg Kroah-Hartman[ Upstream commit 9d3863736a267068a0ae67c6695af8770ef330b7 ]
The lack of defaults provided by the caller to v4l2_fwnode_endpoint_parse() signals the use of the default lane mapping. The default lane mapping must not be used however if the firmmare contains the lane mapping. Disable the default lane mapping in that case, and improve the debug messages telling of the use of the defaults.
This was missed previously since the default mapping will only unsed in this case if the bus type is set, and no driver did both while still needing the lane mapping configuration.
--- drivers/media/v4l2-core/v4l2-fwnode.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/media/v4l2-core/v4l2-fwnode.c +5 -1
@@ -163,7 +163,7 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct fwnode_handle *fwnode, }if (use_default_lane_mapping) -pr_debug ("using default lane mapping\n" ); +pr_debug ("no lane mapping given, using defaults\n" ); } rval =fwnode_property_read_u32_array (fwnode,"data-lanes" ,NULL ,0 );
@@ -175,6 +175,10 @@ static int v4l2_fwnode_endpoint_parse_csi2_bus(struct fwnode_handle *fwnode, num_data_lanes); have_data_lanes = true; +if (use_default_lane_mapping) { +pr_debug ("data-lanes property exists; disabling default mapping\n" ); + use_default_lane_mapping = false; + } }for (i =0 ; i < num_data_lanes; i++) {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 144/155 ARM: dts: exynos: Always enable necessary APIO_1V8 and ABB_1V8 regulators on Arndale Octa
In reply to Greg Kroah-Hartman[ Upstream commit 5ab99cf7d5e96e3b727c30e7a8524c976bd3723d ]
The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned off by Linux kernel as unused. However they supply critical parts of SoC so they should be always on:
1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift, RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt lines, TTL/UARTR level shift, reset pins and SW-TACT1 button. It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and VDDQ_GPIO (gpm7, gpy7).
The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so marking it "always-on" only reflects its real status.
2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores, memory and Mali (G3D).
--- arch/arm/boot/dts/exynos5420-arndale-octa.dts | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/boot/dts/exynos5420-arndale-octa.dts +2 -0
@@ -107,6 +107,7 @@ regulator-name = "PVDD_APIO_1V8"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; + regulator-always-on; }; ldo3_reg: LDO3 {
@@ -145,6 +146,7 @@ regulator-name = "PVDD_ABB_1V8"; regulator-min-microvolt = <1800000>; regulator-max-microvolt = <1800000>; + regulator-always-on; }; ldo9_reg: LDO9 {
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 145/155 pwm: Fix deadlock warning when removing PWM device
In reply to Greg Kroah-Hartman[ Upstream commit 347ab9480313737c0f1aaa08e8f2e1a791235535 ]
This patch fixes deadlock warning if removing PWM device when CONFIG_PROVE_LOCKING is enabled.
This issue can be reproceduced by the following steps on the R-Car H3 Salvator-X board if the backlight is disabled:
# cd /sys/class/pwm/pwmchip0 # echo 0 > export # ls device export npwm power pwm0 subsystem uevent unexport # cd device/driver # ls bind e6e31000.pwm uevent unbind # echo e6e31000.pwm > unbind
[ 87.659974] ======================================================
[ 87.666149] WARNING: possible circular locking dependency detected
[ 87.672327] 5.0.0 #7 Not tainted
[ 87.675549] ------------------------------------------------------
[ 87.681723] bash/2986 is trying to acquire lock:
[ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0
[ 87.694528]
[ 87.694528] but task is already holding lock:
[ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
[ 87.707405]
[ 87.707405] which lock already depends on the new lock.
[ 87.707405]
[ 87.715574]
[ 87.715574] the existing dependency chain (in reverse order) is:
[ 87.723048]
[ 87.723048] -> #1 (pwm_lock){+.+.}:
[ 87.728017] __mutex_lock+0x70/0x7e4
[ 87.732108] mutex_lock_nested+0x1c/0x24
[ 87.736547] pwm_request_from_chip.part.6+0x34/0x74
[ 87.741940] pwm_request_from_chip+0x20/0x40
[ 87.746725] export_store+0x6c/0x1f4
[ 87.750820] dev_attr_store+0x18/0x28
[ 87.754998] sysfs_kf_write+0x54/0x64
[ 87.759175] kernfs_fop_write+0xe4/0x1e8
[ 87.763615] __vfs_write+0x40/0x184
[ 87.767619] vfs_write+0xa8/0x19c
[ 87.771448] ksys_write+0x58/0xbc
[ 87.775278] __arm64_sys_write+0x18/0x20
[ 87.779721] el0_svc_common+0xd0/0x124
[ 87.783986] el0_svc_compat_handler+0x1c/0x24
[ 87.788858] el0_svc_compat+0x8/0x18
[ 87.792947]
[ 87.792947] -> #0 (kn->count#58){++++}:
[ 87.798260] lock_acquire+0xc4/0x22c
[ 87.802353] __kernfs_remove+0x258/0x2c4
[ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0
[ 87.811836] remove_files.isra.1+0x38/0x78
[ 87.816447] sysfs_remove_group+0x48/0x98
[ 87.820971] sysfs_remove_groups+0x34/0x4c
[ 87.825583] device_remove_attrs+0x6c/0x7c
[ 87.830197] device_del+0x11c/0x33c
[ 87.834201] device_unregister+0x14/0x2c
[ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c
[ 87.843509] pwmchip_remove+0xf4/0x13c
[ 87.847773] rcar_pwm_remove+0x28/0x34
[ 87.852039] platform_drv_remove+0x24/0x64
[ 87.856651] device_release_driver_internal+0x18c/0x21c
[ 87.862391] device_release_driver+0x14/0x1c
[ 87.867175] unbind_store+0xe0/0x124
[ 87.871265] drv_attr_store+0x20/0x30
[ 87.875442] sysfs_kf_write+0x54/0x64
[ 87.879618] kernfs_fop_write+0xe4/0x1e8
[ 87.884055] __vfs_write+0x40/0x184
[ 87.888057] vfs_write+0xa8/0x19c
[ 87.891887] ksys_write+0x58/0xbc
[ 87.895716] __arm64_sys_write+0x18/0x20
[ 87.900154] el0_svc_common+0xd0/0x124
[ 87.904417] el0_svc_compat_handler+0x1c/0x24
[ 87.909289] el0_svc_compat+0x8/0x18
[ 87.913378]
[ 87.913378] other info that might help us debug this:
[ 87.913378]
[ 87.921374] Possible unsafe locking scenario:
[ 87.921374]
[ 87.927286] CPU0 CPU1
[ 87.931808] ---- ----
[ 87.936331] lock(pwm_lock);
[ 87.939293] lock(kn->count#58);
[ 87.945120] lock(pwm_lock);
[ 87.950599] lock(kn->count#58);
[ 87.953908]
[ 87.953908] *** DEADLOCK ***
[ 87.953908]
[ 87.959821] 4 locks held by bash/2986:
[ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c
[ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8
[ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c
[ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c
[ 87.995481]
[ 87.995481] stack backtrace:
[ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7
[ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT)
[ 88.012791] Call trace:
[ 88.015235] dump_backtrace+0x0/0x190
[ 88.018891] show_stack+0x14/0x1c
[ 88.022204] dump_stack+0xb0/0xec
[ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0
[ 88.030385] __lock_acquire+0x1318/0x1864
[ 88.034388] lock_acquire+0xc4/0x22c
[ 88.037958] __kernfs_remove+0x258/0x2c4
[ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0
[ 88.046398] remove_files.isra.1+0x38/0x78
[ 88.050487] sysfs_remove_group+0x48/0x98
[ 88.054490] sysfs_remove_groups+0x34/0x4c
[ 88.058580] device_remove_attrs+0x6c/0x7c
[ 88.062671] device_del+0x11c/0x33c
[ 88.066154] device_unregister+0x14/0x2c
[ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c
[ 88.074421] pwmchip_remove+0xf4/0x13c
[ 88.078163] rcar_pwm_remove+0x28/0x34
[ 88.081906] platform_drv_remove+0x24/0x64
[ 88.085996] device_release_driver_internal+0x18c/0x21c
[ 88.091215] device_release_driver+0x14/0x1c
[ 88.095478] unbind_store+0xe0/0x124
[ 88.099048] drv_attr_store+0x20/0x30
[ 88.102704] sysfs_kf_write+0x54/0x64
[ 88.106359] kernfs_fop_write+0xe4/0x1e8
[ 88.110275] __vfs_write+0x40/0x184
[ 88.113757] vfs_write+0xa8/0x19c
[ 88.117065] ksys_write+0x58/0xbc
[ 88.120374] __arm64_sys_write+0x18/0x20
[ 88.124291] el0_svc_common+0xd0/0x124
[ 88.128034] el0_svc_compat_handler+0x1c/0x24
[ 88.132384] el0_svc_compat+0x8/0x18The sysfs unexport in pwmchip_remove() is completely asymmetric to what we do in pwmchip_add_with_polarity() and commit 0733424c9ba9 ("pwm: Unexport children before chip removal") is a strong indication that this was wrong to begin with. We should just move pwmchip_sysfs_unexport() where it belongs, which is right after pwmchip_sysfs_unexport_children(). In that case, we do not need separate functions anymore either.
We also really want to remove sysfs irrespective of whether or not the chip will be removed as a result of pwmchip_remove(). We can only assume that the driver will be gone after that, so we shouldn't leave any dangling sysfs files around.
This warning disappears if we move pwmchip_sysfs_unexport() to the top of pwmchip_remove(), pwmchip_sysfs_unexport_children(). That way it is also outside of the pwm_lock section, which indeed doesn't seem to be needed.
Moving the pwmchip_sysfs_export() call outside of that section also seems fine and it'd be perfectly symmetric with pwmchip_remove() again.
So, this patch fixes them.
--- drivers/pwm/core.c | 10 +++++----- drivers/pwm/sysfs.c | 14 +------------- include/linux/pwm.h | 5 ----- 3 files changed, 6 insertions(+), 23 deletions(-)
drivers/pwm/core.c +5 -5
@@ -311,10 +311,12 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,if (IS_ENABLED (CONFIG_OF ))of_pwmchip_add (chip); -pwmchip_sysfs_export (chip); - out:mutex_unlock (&pwm_lock); + +if (!ret) +pwmchip_sysfs_export (chip); +return ret; }EXPORT_SYMBOL_GPL (pwmchip_add_with_polarity);
@@ -348,7 +350,7 @@ int pwmchip_remove(struct pwm_chip *chip)unsigned int i;int ret =0 ; -pwmchip_sysfs_unexport_children (chip); +pwmchip_sysfs_unexport (chip);mutex_lock (&pwm_lock);
@@ -368,8 +370,6 @@ int pwmchip_remove(struct pwm_chip *chip)free_pwms (chip); -pwmchip_sysfs_unexport (chip); - out:mutex_unlock (&pwm_lock);return ret;
drivers/pwm/sysfs.c +1 -13
@@ -409,19 +409,6 @@ void pwmchip_sysfs_export(struct pwm_chip *chip) }void pwmchip_sysfs_unexport (struct pwm_chip *chip) -{ -struct device *parent; - - parent =class_find_device (&pwm_class,NULL , chip, - pwmchip_sysfs_match); -if (parent) { -/* for class_find_device() */ -put_device (parent); -device_unregister (parent); - } -} - -void pwmchip_sysfs_unexport_children (struct pwm_chip *chip) {struct device *parent;unsigned int i;
@@ -439,6 +426,7 @@ void pwmchip_sysfs_unexport_children(struct pwm_chip *chip) }put_device (parent); +device_unregister (parent); }static int __init pwm_sysfs_init (void )
include/linux/pwm.h +0 -5
@@ -596,7 +596,6 @@ static inline void pwm_remove_table(struct pwm_lookup *table, size_t num)#ifdef CONFIG_PWM_SYSFS void pwmchip_sysfs_export (struct pwm_chip *chip);void pwmchip_sysfs_unexport (struct pwm_chip *chip); -void pwmchip_sysfs_unexport_children (struct pwm_chip *chip);#else static inline void pwmchip_sysfs_export (struct pwm_chip *chip) {
@@ -605,10 +604,6 @@ static inline void pwmchip_sysfs_export(struct pwm_chip *chip)static inline void pwmchip_sysfs_unexport (struct pwm_chip *chip) { } - -static inline void pwmchip_sysfs_unexport_children (struct pwm_chip *chip) -{ -}#endif /* CONFIG_PWM_SYSFS */ #endif /* __LINUX_PWM_H */
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 146/155 ARM: exynos: Fix undefined instruction during Exynos5422 resume
In reply to Greg Kroah-Hartman[ Upstream commit 4d8e3e951a856777720272ce27f2c738a3eeef8c ]
During early system resume on Exynos5422 with performance counters enabled the following kernel oops happens:
Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 1433 Comm: bash Tainted: G W 5.0.0-rc5-next-20190208-00023-gd5fb5a8a13e6-dirty #5480
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
...
Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 4451006a DAC: 00000051
Process bash (pid: 1433, stack limit = 0xb7e0e22f)
...
(reset_ctrl_regs) from [<c0112ad0>] (dbg_cpu_pm_notify+0x1c/0x24)
(dbg_cpu_pm_notify) from [<c014c840>] (notifier_call_chain+0x44/0x84)
(notifier_call_chain) from [<c014cbc0>] (__atomic_notifier_call_chain+0x7c/0x128)
(__atomic_notifier_call_chain) from [<c01ffaac>] (cpu_pm_notify+0x30/0x54)
(cpu_pm_notify) from [<c055116c>] (syscore_resume+0x98/0x3f4)
(syscore_resume) from [<c0189350>] (suspend_devices_and_enter+0x97c/0xe74)
(suspend_devices_and_enter) from [<c0189fb8>] (pm_suspend+0x770/0xc04)
(pm_suspend) from [<c0187740>] (state_store+0x6c/0xcc)
(state_store) from [<c09fa698>] (kobj_attr_store+0x14/0x20)
(kobj_attr_store) from [<c030159c>] (sysfs_kf_write+0x4c/0x50)
(sysfs_kf_write) from [<c0300620>] (kernfs_fop_write+0xfc/0x1e0)
(kernfs_fop_write) from [<c0282be8>] (__vfs_write+0x2c/0x160)
(__vfs_write) from [<c0282ea4>] (vfs_write+0xa4/0x16c)
(vfs_write) from [<c0283080>] (ksys_write+0x40/0x8c)
(ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28)Undefined instruction is triggered during CP14 reset, because bits: #16 (Secure privileged invasive debug disabled) and #17 (Secure privileged noninvasive debug disable) are set in DSCR. Those bits depend on SPNIDEN and SPIDEN lines, which are provided by Secure JTAG hardware block. That block in turn is powered from cluster 0 (big/Eagle), but the Exynos5422 boots on cluster 1 (LITTLE/KFC).
To fix this issue it is enough to turn on the power on the cluster 0 for a while. This lets the Secure JTAG block to propagate the needed signals to LITTLE/KFC cores and change their DSCR.
--- arch/arm/mach-exynos/suspend.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
arch/arm/mach-exynos/suspend.c +19 -0
@@ -444,8 +444,27 @@ early_wakeup:static void exynos5420_prepare_pm_resume (void ) { +unsigned int mpidr, cluster; + + mpidr =read_cpuid_mpidr (); + cluster =MPIDR_AFFINITY_LEVEL (mpidr,1 ); +if (IS_ENABLED (CONFIG_EXYNOS5420_MCPM ))WARN_ON (mcpm_cpu_powered_up ()); + +if (IS_ENABLED (CONFIG_HW_PERF_EVENTS ) && cluster !=0 ) { +/* +* When system is resumed on the LITTLE/KFC core (cluster 1), +* the DSCR is not properly updated until the power is turned +* on also for the cluster 0. Enable it for a while to +* propagate the SPNIDEN and SPIDEN signals from Secure JTAG +* block and avoid undefined instruction issue on CP14 reset. +*/ +pmu_raw_writel (S5P_CORE_LOCAL_PWR_EN , +EXYNOS_COMMON_CONFIGURATION (0 )); +pmu_raw_writel (0 , +EXYNOS_COMMON_CONFIGURATION (0 )); + } }static void exynos5420_pm_resume (void )
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 147/155 usb: typec: fusb302: Check vconn is off when we start toggling
In reply to Greg Kroah-Hartman[ Upstream commit 32a155b1a83d6659e2272e8e1eec199667b1897e ]
The datasheet says the vconn MUST be off when we start toggling. The tcpm.c state-machine is responsible to make sure vconn is off, but lets add a WARN to catch any cases where vconn is not off for some reason.
--- drivers/usb/typec/tcpm/fusb302.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/typec/tcpm/fusb302.c +2 -0
@@ -634,6 +634,8 @@ static int fusb302_set_toggling(struct fusb302_chip *chip,return ret; chip->intr_togdone = false; }else { +/* Datasheet says vconn MUST be off when toggling */ +WARN (chip->vconn_on,"Vconn is on during toggle start" );/* unmask TOGDONE interrupt */ ret =fusb302_i2c_clear_bits (chip,FUSB_REG_MASKA ,FUSB_REG_MASKA_TOGDONE );
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 148/155 soc: renesas: Identify R-Car M3-W ES1.3
In reply to Greg Kroah-Hartman[ Upstream commit 15160f6de0bba712fcea078c5ac7571fe33fcd5d ]
The Product Register of R-Car M3-W ES1.3 incorrectly identifies the SoC revision as ES2.1. Add a workaround to fix this.
--- drivers/soc/renesas/renesas-soc.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/soc/renesas/renesas-soc.c +3 -0
@@ -335,6 +335,9 @@ static int __init renesas_soc_init(void)/* R-Car M3-W ES1.1 incorrectly identifies as ES2.0 */ if ((product &0x7fff ) ==0x5210 ) product ^=0x11 ; +/* R-Car M3-W ES1.3 incorrectly identifies as ES2.1 */ +if ((product &0x7fff ) ==0x5211 ) + product ^=0x12 ;if (soc->id && ((product >>8 ) &0xff ) != soc->id) {pr_warn ("SoC mismatch (product = 0x%x)\n" , product);return -ENODEV ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 149/155 ARM: shmobile: porter: enable R-Car Gen2 regulator quirk
In reply to Greg Kroah-Hartman[ Upstream commit d5aa84087eadd6f2619628bc9f3d028eeabded0f ]
Porter needs the regulator quirk, just like the other boards. But unlike the other boards, the Porter uses DA9063L, which is at 0x5a. Otherwise, DA9063L and DA9210 IRQ line is still connected to CPU IRQ2 .
--- arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c +4 -2
@@ -1,6 +1,6 @@// SPDX-License-Identifier: GPL-2.0 /* -* R-Car Generation 2 da9063/da9210 regulator quirk +* R-Car Generation 2 da9063(L)/da9210 regulator quirk * * Certain Gen2 development boards have an da9063 and one or more da9210 * regulators. All of these regulators have their interrupt request lines
@@ -65,6 +65,7 @@ static struct i2c_msg da9210_msg = {static const struct of_device_id rcar_gen2_quirk_match[] = { { .compatible ="dlg,da9063" , .data = &da9063_msg }, + { .compatible ="dlg,da9063l" , .data = &da9063_msg }, { .compatible ="dlg,da9210" , .data = &da9210_msg }, {}, };
@@ -147,6 +148,7 @@ static int __init rcar_gen2_regulator_quirk(void)if (!of_machine_is_compatible ("renesas,koelsch" ) && !of_machine_is_compatible ("renesas,lager" ) && + !of_machine_is_compatible ("renesas,porter" ) && !of_machine_is_compatible ("renesas,stout" ) && !of_machine_is_compatible ("renesas,gose" ))return -ENODEV ;
@@ -210,7 +212,7 @@ static int __init rcar_gen2_regulator_quirk(void) goto err_free; } -pr_info ("IRQ2 is asserted, installing da9063/da9210 regulator quirk\n" ); +pr_info ("IRQ2 is asserted, installing regulator quirk\n" );bus_register_notifier (&i2c_bus_type, ®ulator_quirk_nb);return 0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 150/155 gpio: vf610: Do not share irq_chip
In reply to Greg Kroah-Hartman[ Upstream commit 338aa10750ba24d04beeaf5dc5efc032e5cf343f ]
Fix the warning produced by gpiochip_set_irq_hooks() by allocating a dedicated IRQ chip per GPIO chip/port.
--- drivers/gpio/gpio-vf610.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-)
drivers/gpio/gpio-vf610.c +12 -14
@@ -29,6 +29,7 @@ struct fsl_gpio_soc_data {struct vf610_gpio_port {struct gpio_chip gc; +struct irq_chip ic;void __iomem *base;void __iomem *gpio_base;const struct fsl_gpio_soc_data *sdata;
@@ -60,8 +61,6 @@ struct vf610_gpio_port {#define PORT_INT_EITHER_EDGE 0xb#define PORT_INT_LOGIC_ONE 0xc -static struct irq_chip vf610_gpio_irq_chip; -static const struct fsl_gpio_soc_data imx_data = { .have_paddr = true, };
@@ -237,15 +236,6 @@ static int vf610_gpio_irq_set_wake(struct irq_data *d, u32 enable)return 0 ; } -static struct irq_chip vf610_gpio_irq_chip = { - .name ="gpio-vf610" , - .irq_ack = vf610_gpio_irq_ack, - .irq_mask = vf610_gpio_irq_mask, - .irq_unmask = vf610_gpio_irq_unmask, - .irq_set_type = vf610_gpio_irq_set_type, - .irq_set_wake = vf610_gpio_irq_set_wake, -}; -static int vf610_gpio_probe (struct platform_device *pdev) {struct device *dev = &pdev->dev;
@@ -253,6 +243,7 @@ static int vf610_gpio_probe(struct platform_device *pdev)struct vf610_gpio_port *port;struct resource *iores;struct gpio_chip *gc; +struct irq_chip *ic;int i;int ret;
@@ -316,6 +307,14 @@ static int vf610_gpio_probe(struct platform_device *pdev) gc->direction_output = vf610_gpio_direction_output; gc->set = vf610_gpio_set; + ic = &port->ic; + ic->name ="gpio-vf610" ; + ic->irq_ack = vf610_gpio_irq_ack; + ic->irq_mask = vf610_gpio_irq_mask; + ic->irq_unmask = vf610_gpio_irq_unmask; + ic->irq_set_type = vf610_gpio_irq_set_type; + ic->irq_set_wake = vf610_gpio_irq_set_wake; + ret =gpiochip_add_data (gc, port);if (ret <0 )return ret;
@@ -327,14 +326,13 @@ static int vf610_gpio_probe(struct platform_device *pdev)/* Clear the interrupt status register for all GPIO's */ vf610_gpio_writel (~0 , port->base +PORT_ISFR ); - ret =gpiochip_irqchip_add (gc, &vf610_gpio_irq_chip,0 , - handle_edge_irq,IRQ_TYPE_NONE ); + ret =gpiochip_irqchip_add (gc, ic,0 , handle_edge_irq,IRQ_TYPE_NONE );if (ret) {dev_err (dev,"failed to add irqchip\n" );gpiochip_remove (gc);return ret; } -gpiochip_set_chained_irqchip (gc, &vf610_gpio_irq_chip, port->irq, +gpiochip_set_chained_irqchip (gc, ic, port->irq, vf610_gpio_irq_handler);return 0 ;
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 151/155 percpu: do not search past bitmap when allocating an area
In reply to Greg Kroah-Hartman[ Upstream commit 8c43004af01635cc9fbb11031d070e5e0d327ef2 ]
pcpu_find_block_fit() guarantees that a fit is found within PCPU_BITMAP_BLOCK_BITS. Iteration is used to determine the first fit as it compares against the block's contig_hint. This can lead to incorrectly scanning past the end of the bitmap. The behavior was okay given the check after for bit_off >= end and the correctness of the hints from pcpu_find_block_fit().
This patch fixes this by bounding the end offset by the number of bits in a chunk.
--- mm/percpu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
mm/percpu.c +2 -1
@@ -988,7 +988,8 @@ static int pcpu_alloc_area(struct pcpu_chunk *chunk, int alloc_bits,/* * Search to find a fit. */ - end = start + alloc_bits +PCPU_BITMAP_BLOCK_BITS ; + end =min_t (int, start + alloc_bits +PCPU_BITMAP_BLOCK_BITS , +pcpu_chunk_map_bits (chunk)); bit_off =bitmap_find_next_zero_area (chunk->alloc_map, end, start, alloc_bits, align_mask);if (bit_off >= end)
Signature · 1 line
2.20.1
Greg Kroah-Hartman
maintainerPATCH 152/155 Revert "Bluetooth: Align minimum encryption key size for LE and BR/EDR connections"
In reply to Greg Kroah-HartmanFrom: Greg Kroah-Hartman <[email protected]>
This reverts commit 07e38998a19d72b916c39a983c19134522ae806b which is commit d5bb334a8e171b262e48f378bd2096c0ea458265 upstream.
Lots of people have reported issues with this patch, and as there does not seem to be a fix going into Linus's kernel tree any time soon, revert the commit in the stable trees so as to get people's machines working properly again.
--- include/net/bluetooth/hci_core.h | 3 --- net/bluetooth/hci_conn.c | 8 -------- 2 files changed, 11 deletions(-)
include/net/bluetooth/hci_core.h +0 -3
@@ -190,9 +190,6 @@ struct adv_info {#define HCI_MAX_SHORT_NAME_LENGTH 10 -/* Min encryption key size to match with SMP */ -#define HCI_MIN_ENC_KEY_SIZE 7 -/* Default LE RPA expiry time, 15 minutes */ #define HCI_DEFAULT_RPA_TIMEOUT (15 * 60)
net/bluetooth/hci_conn.c +0 -8
@@ -1276,14 +1276,6 @@ int hci_conn_check_link_mode(struct hci_ !test_bit(HCI_CONN_ENCRYPT, &conn->flags))return 0 ; -/* The minimum encryption key size needs to be enforced by the -* host stack before establishing any L2CAP connections. The -* specification in theory allows a minimum of 1, but to align -* BR/EDR and LE transports, a minimum of 7 is chosen. -*/ -if (conn->enc_key_size <HCI_MIN_ENC_KEY_SIZE ) -return 0 ; -return 1 ; }
Greg Kroah-Hartman
maintainerPATCH 153/155 Revert "drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)"
In reply to Greg Kroah-HartmanFrom: Greg Kroah-Hartman <[email protected]>
This reverts commit 1e07d637497788971018d9e9e5a184940b1ade0f which is commit b30a43ac7132cdda833ac4b13dd1ebd35ace14b7 upstream.
Sven reports:
Commit 1e07d63749 ("drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)") has caused a build failure for me when I actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n):
,----
| Kernel: arch/x86/boot/bzImage is ready (#1)
| Building modules, stage 2.
| MODPOST 290 modules
| ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! | scripts/Makefile.modpost:91: recipe for target '__modpost' failed `----
Upstream does not have that problem, as commit bed2dd8421 ("drm/ttm:
Quick-test mmap offset in ttm_bo_mmap()") has removed the use of drm_legacy_mmap from nouveau_ttm.c. Unfortunately that commit does not apply in 5.1.9.
The ensuing discussion proposed a number of one-off patches, but no solid agreement was made, so just revert the commit for now to get people's systems building again.
--- drivers/gpu/drm/nouveau/Kconfig | 13 +------------ drivers/gpu/drm/nouveau/nouveau_drm.c | 7 ++----- 2 files changed, 3 insertions(+), 17 deletions(-)
drivers/gpu/drm/nouveau/Kconfig +1 -12
@@ -17,20 +17,9 @@ config DRM_NOUVEAU select INPUT if ACPI && X86 select THERMAL if ACPI && X86 select ACPI_VIDEO if ACPI && X86 - help - Choose this option for open-source NVIDIA support. - -config NOUVEAU_LEGACY_CTX_SUPPORT - bool "Nouveau legacy context support" - depends on DRM_NOUVEAU select DRM_VM - default y help - There was a version of the nouveau DDX that relied on legacy - ctx ioctls not erroring out. But that was back in time a long - ways, so offer a way to disable it now. For uapi compat with - old nouveau ddx this should be on by default, but modern distros - should consider turning it off. + Choose this option for open-source NVIDIA support. config NOUVEAU_PLATFORM_DRIVER bool "Nouveau (NVIDIA) SoC GPUs"
drivers/gpu/drm/nouveau/nouveau_drm.c +2 -5
@@ -1094,11 +1094,8 @@ nouveau_driver_fops = {static struct drm_driver driver_stub = { .driver_features = -DRIVER_GEM |DRIVER_MODESET |DRIVER_PRIME |DRIVER_RENDER -#if defined(CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) - |DRIVER_KMS_LEGACY_CONTEXT -#endif - , +DRIVER_GEM |DRIVER_MODESET |DRIVER_PRIME |DRIVER_RENDER | +DRIVER_KMS_LEGACY_CONTEXT , .open = nouveau_drm_open, .postclose = nouveau_drm_postclose,
Greg Kroah-Hartman
maintainerPATCH 154/155 ovl: check the capability before cred overridden
In reply to Greg Kroah-HartmanFrom: Jiufei Xue <[email protected]>
commit 98487de318a6f33312471ae1e2afa16fbf8361fe upstream.
We found that it return success when we set IMMUTABLE_FL flag to a file in docker even though the docker didn't have the capability CAP_LINUX_IMMUTABLE.
The commit d1d04ef8572b ("ovl: stack file ops") and dab5ca8fd9dd ("ovl: add lsattr/chattr support") implemented chattr operations on a regular overlay file. ovl_real_ioctl() overridden the current process's subjective credentials with ofs->creator_cred which have the capability CAP_LINUX_IMMUTABLE so that it will return success in vfs_ioctl()->cap_capable().
Fix this by checking the capability before cred overridden. And here we only care about APPEND_FL and IMMUTABLE_FL, so get these information from inode.
[SzM: move check and call to underlying fs inside inode locked region to prevent two such calls from racing with each other]
--- fs/overlayfs/file.c | 79 ++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 61 insertions(+), 18 deletions(-)
fs/overlayfs/file.c +61 -18
@@ -11,6 +11,7 @@#include <linux/mount.h> #include <linux/xattr.h> #include <linux/uio.h> +#include <linux/uaccess.h> #include "overlayfs.h" static char ovl_whatisit (struct inode *inode,struct inode *realinode)
@@ -372,10 +373,68 @@ static long ovl_real_ioctl(struct file *return ret; } -static long ovl_ioctl (struct file *file,unsigned int cmd,unsigned long arg) +static unsigned int ovl_get_inode_flags (struct inode *inode) +{ +unsigned int flags =READ_ONCE (inode->i_flags); +unsigned int ovl_iflags =0 ; + +if (flags &S_SYNC ) + ovl_iflags |=FS_SYNC_FL ; +if (flags &S_APPEND ) + ovl_iflags |=FS_APPEND_FL ; +if (flags &S_IMMUTABLE ) + ovl_iflags |=FS_IMMUTABLE_FL ; +if (flags &S_NOATIME ) + ovl_iflags |=FS_NOATIME_FL ; + +return ovl_iflags; +} + +static long ovl_ioctl_set_flags (struct file *file,unsigned long arg) {long ret;struct inode *inode =file_inode (file); +unsigned int flags; +unsigned int old_flags; + +if (!inode_owner_or_capable (inode)) +return -EACCES ; + +if (get_user (flags, (int __user *) arg)) +return -EFAULT ; + + ret =mnt_want_write_file (file); +if (ret) +return ret; + +inode_lock (inode); + +/* Check the capability before cred override */ + ret = -EPERM ; + old_flags =ovl_get_inode_flags (inode); +if (((flags ^ old_flags) & (FS_APPEND_FL |FS_IMMUTABLE_FL )) && + !capable (CAP_LINUX_IMMUTABLE )) + goto unlock; + + ret =ovl_maybe_copy_up (file_dentry (file),O_WRONLY ); +if (ret) + goto unlock; + + ret =ovl_real_ioctl (file,FS_IOC_SETFLAGS , arg); + +ovl_copyflags (ovl_inode_real (inode), inode); +unlock: +inode_unlock (inode); + +mnt_drop_write_file (file); + +return ret; + +} + +static long ovl_ioctl (struct file *file,unsigned int cmd,unsigned long arg) +{ +long ret;switch (cmd) {case FS_IOC_GETFLAGS :
@@ -383,23 +442,7 @@ static long ovl_ioctl(struct file *file,break ;case FS_IOC_SETFLAGS : -if (!inode_owner_or_capable (inode)) -return -EACCES ; - - ret =mnt_want_write_file (file); -if (ret) -return ret; - - ret =ovl_maybe_copy_up (file_dentry (file),O_WRONLY ); -if (!ret) { - ret =ovl_real_ioctl (file, cmd, arg); - -inode_lock (inode); -ovl_copyflags (ovl_inode_real (inode), inode); -inode_unlock (inode); - } - -mnt_drop_write_file (file); + ret =ovl_ioctl_set_flags (file, arg);break ;default :
Greg Kroah-Hartman
maintainerPATCH 155/155 ovl: support stacked SEEK_HOLE/SEEK_DATA
In reply to Greg Kroah-HartmanFrom: Amir Goldstein <[email protected]>
commit 9e46b840c7053b5f7a245e98cd239b60d189a96c upstream.
Overlay file f_pos is the master copy that is preserved through copy up and modified on read/write, but only real fs knows how to SEEK_HOLE/SEEK_DATA and real fs may impose limitations that are more strict than ->s_maxbytes for specific files, so we use the real file to perform seeks.
We do not call real fs for SEEK_CUR:0 query and for SEEK_SET:0 requests.
--- fs/overlayfs/file.c | 44 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 4 deletions(-)
fs/overlayfs/file.c +40 -4
@@ -146,11 +146,47 @@ static int ovl_release(struct inode *inostatic loff_t ovl_llseek (struct file *file,loff_t offset,int whence) { -struct inode *realinode =ovl_inode_real (file_inode (file)); +struct inode *inode =file_inode (file); +struct fd real; +const struct cred *old_cred; +ssize_t ret; -return generic_file_llseek_size (file, offset, whence, - realinode->i_sb->s_maxbytes, -i_size_read (realinode)); +/* +* The two special cases below do not need to involve real fs, +* so we can optimizing concurrent callers. +*/ +if (offset ==0 ) { +if (whence ==SEEK_CUR ) +return file->f_pos; + +if (whence ==SEEK_SET ) +return vfs_setpos (file,0 ,0 ); + } + + ret =ovl_real_fdget (file, &real); +if (ret) +return ret; + +/* +* Overlay file f_pos is the master copy that is preserved +* through copy up and modified on read/write, but only real +* fs knows how to SEEK_HOLE/SEEK_DATA and real fs may impose +* limitations that are more strict than ->s_maxbytes for specific +* files, so we use the real file to perform seeks. +*/ +inode_lock (inode); + real.file->f_pos = file->f_pos; + + old_cred =ovl_override_creds (inode->i_sb); + ret =vfs_llseek (real.file, offset, whence); +revert_creds (old_cred); + + file->f_pos = real.file->f_pos; +inode_unlock (inode); + +fdput (real); + +return ret; }static void ovl_file_accessed (struct file *file)
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.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: 5.1.10-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.1.y
git commit: b7eabc3862b8717f2bcc47f3f3830ec575423c8c
git describe: v5.1.9-157-gb7eabc3862b8
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.1-oe/build/v5.1.9-157-gb7eabc3862b8
No regressions (compared to build v5.1.8-72-g2df16141a2c4)
No fixes (compared to build v5.1.8-72-g2df16141a2c4)
Ran 23163 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
Test Suites
-----------
* build
* install-android-platform-tools-r2600
* kselftest
* libgpiod
* libhugetlbfs
* ltp-commands-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-sched-tests
* spectre-meltdown-checker-test
* ltp-cap_bounds-tests
* ltp-cpuhotplug-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* network-basic-tests
* perf
* v4l2-compliance
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 17 lines · Naresh Kamboju
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.y
and the diffstat can be found below.
Quoted 7 lines
Quoted 4 lines
thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm,x86_64, and i386.
Thanks for testing all of these and letting me know.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
Build results:
total: 159 pass: 159 fail: 0 Qemu test results: total: 354 pass: 354 fail: 0
Guenter
Greg Kroah-Hartman
maintainerQuoted 6 lines · Guenter Roeck
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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.
Quoted 8 lines
Quoted 3 lines
Responses should be made by Sat 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
Build results:
total: 159 pass: 159 fail: 0 Qemu test results: total: 354 pass: 354 fail: 0
Great, thanks for testing and letting me know.
greg k-h
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.y
and the diffstat can be found below.
Quoted 5 lines
thanks,
greg k-h
-------------
Compiled and booted. No regressions on x86_64.
This is for 5.1.10-rc2 from git --no-pager log --oneline -1.
THX
Greg Kroah-Hartman
maintainerQuoted 15 lines · Jiunn Chang
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.y
and the diffstat can be found below.
Quoted 8 lines
Quoted 5 lines
thanks,
greg k-h
-------------
Compiled and booted. No regressions on
x86_64.This is for 5.1.10-rc2 from git --no-pager log --oneline -1.
What do you mean by 'git --no-pager log --oneline -1' ?
thanks for testing,
greg k-h
Quoted 18 lines · Greg Kroah-Hartman
Quoted 17 lines · Jiunn Chang
Quoted 16 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.y
and the diffstat can be found below.thanks,
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
greg k-h
-------------
Compiled and booted. No regressions on
x86_64.This is for 5.1.10-rc2 from git --no-pager log --oneline -1.
What do you mean by 'git --no-pager log --oneline -1' ?
Hello. I must have missed an email somewhere. The review request was for 5.1.10-rc1 but I only had 5.1.10-rc2 from the logs. Sorry for the confusion.
Quoted 4 lines
thanks for testing,
greg k-h
Greg Kroah-Hartman
maintainerQuoted 22 lines · Jiunn Chang
Quoted 21 lines · Greg Kroah-Hartman
Quoted 20 lines · Jiunn Chang
Quoted 19 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Compiled and booted. No regressions on
x86_64.This is for 5.1.10-rc2 from git --no-pager log --oneline -1.
What do you mean by 'git --no-pager log --oneline -1' ?
Hello. I must have missed an email somewhere. The review request was for 5.1.10-rc1 but I only had 5.1.10-rc2 from the logs. Sorry for the confusion.
Ah, thanks, that made sense. I pushed out a -rc2 because of some missed patches and dropping one as well.
thanks,
greg k-h
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Greg Kroah-Hartman
maintainerQuoted 15 lines · shuah
Quoted 14 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.y
and the diffstat can be found below.
Quoted 6 lines
Quoted 4 lines
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Great, thanks for testing and letting me know.
greg k-h
Jon Hunter
maintainerQuoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.y
and the diffstat can be found below.thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.1:
12 builds: 12 pass, 0 fail
22 boots: 22 pass, 0 fail
32 tests: 32 pass, 0 failLinux version: 5.1.10-rc2-gb7eabc3862b8
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04Cheers
Jon
Signature · 1 line
nvpublic
Greg Kroah-Hartman
maintainerQuoted 23 lines · Jon Hunter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.1.10 release. There are 155 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 15 Jun 2019 07:54:40 AM UTC. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.1.y
and the diffstat can be found below.thanks,
greg k-h
All tests are passing for Tegra ...
Test results for stable-v5.1:
Quoted 9 lines
12 builds: 12 pass, 0 fail 22 boots: 22 pass, 0 fail 32 tests: 32 pass, 0 failLinux version: 5.1.10-rc2-gb7eabc3862b8
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,tegra194-p2972-0000, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Wonderful, thanks for testing all of these and letting me know.
greg k-h