aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-01-28nvme-pci: add the DISABLE_WRITE_ZEROES quirk for a SPCC deviceChaitanya Kulkarni1-0/+2
This adds a quirk for SPCC 256GB NVMe 1.3 drive which fixes timeouts and I/O errors due to the fact that the controller does not properly handle the Write Zeroes command: [ 2745.659527] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G E 5.10.6-BET #1 [ 2745.659528] Hardware name: System manufacturer System Product Name/PRIME X570-P, BIOS 3001 12/04/2020 [ 2776.138874] nvme nvme1: I/O 414 QID 3 timeout, aborting [ 2776.138886] nvme nvme1: I/O 415 QID 3 timeout, aborting [ 2776.138891] nvme nvme1: I/O 416 QID 3 timeout, aborting [ 2776.138895] nvme nvme1: I/O 417 QID 3 timeout, aborting [ 2776.138912] nvme nvme1: Abort status: 0x0 [ 2776.138921] nvme nvme1: I/O 428 QID 3 timeout, aborting [ 2776.138922] nvme nvme1: Abort status: 0x0 [ 2776.138925] nvme nvme1: Abort status: 0x0 [ 2776.138974] nvme nvme1: Abort status: 0x0 [ 2776.138977] nvme nvme1: Abort status: 0x0 [ 2806.346792] nvme nvme1: I/O 414 QID 3 timeout, reset controller [ 2806.363566] nvme nvme1: 15/0/0 default/read/poll queues [ 2836.554298] nvme nvme1: I/O 415 QID 3 timeout, disable controller [ 2836.672064] blk_update_request: I/O error, dev nvme1n1, sector 16350 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672072] blk_update_request: I/O error, dev nvme1n1, sector 16093 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672074] blk_update_request: I/O error, dev nvme1n1, sector 15836 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672076] blk_update_request: I/O error, dev nvme1n1, sector 15579 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672078] blk_update_request: I/O error, dev nvme1n1, sector 15322 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672080] blk_update_request: I/O error, dev nvme1n1, sector 15065 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672082] blk_update_request: I/O error, dev nvme1n1, sector 14808 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672083] blk_update_request: I/O error, dev nvme1n1, sector 14551 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672085] blk_update_request: I/O error, dev nvme1n1, sector 14294 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672087] blk_update_request: I/O error, dev nvme1n1, sector 14037 op 0x9:(WRITE_ZEROES) flags 0x0 phys_seg 0 prio class 0 [ 2836.672121] nvme nvme1: failed to mark controller live state [ 2836.672123] nvme nvme1: Removing after probe failure status: -19 [ 2836.689016] Aborting journal on device dm-0-8. [ 2836.689024] Buffer I/O error on dev dm-0, logical block 25198592, lost sync page write [ 2836.689027] JBD2: Error -5 detected when updating journal superblock for dm-0-8. Reported-by: Bradley Chapman <[email protected]> Signed-off-by: Chaitanya Kulkarni <[email protected]> Tested-by: Bradley Chapman <[email protected]> Reviewed-by: Keith Busch <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2021-01-28Merge tag 'for-linus-5.11-rc6-tag' of ↵Linus Torvalds5-14/+54
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen fixes from Juergen Gross: - A fix for a regression introduced in 5.11 resulting in Xen dom0 having problems to correctly initialize Xenstore. - A fix for avoiding WARN splats when booting as Xen dom0 with CONFIG_AMD_MEM_ENCRYPT enabled due to a missing trap handler for the #VC exception (even if the handler should never be called). - A fix for the Xen bklfront driver adapting to the correct but unexpected behavior of new qemu. * tag 'for-linus-5.11-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabled xen: Fix XenStore initialisation for XS_LOCAL xen-blkfront: allow discard-* nodes to be optional
2021-01-28Merge tag 'asm-generic-fixes-v5.11' of ↵Linus Torvalds3-18/+20
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pull ia64 fixes from Arnd Bergmann: "asm-generic/ia64 fixes, and mark as orphaned Commit 2b49ddcef297 ("ia64: convert to legacy_timer_tick") from my timer series I merged through the asm-generic tree caused a regression on all ia64 machines, as bisected by Adrian Glaubitz. Tony Luck is no longer really working on ia64, so instead of merging the fix through his tree, we ended up deciding that I'd merge the fix myself along a patch to mark the architecture as Orphaned and a compile time warning fix I made while working on the regression" [ HPE no longer accepts orders for new Itanium hardware, and Intel stopped accepting orders a year ago. While intel is still officially shipping chips until July 29, 2021, it's unlikely that any such orders actually exist. It's dead, Jim. - Linus ] * tag 'asm-generic-fixes-v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: ia64: Mark architecture as orphaned ia64: fix xchg() warning ia64: fix timer cleanup regression
2021-01-28Merge tag 'arm-soc-fixes-v5.11-2' of ↵Linus Torvalds21-16/+164
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "These are the current arm-soc bug fixes for linux-5.11. I already merged a larger set that just came in during the past three days but has not had much exposure in linux-next, but this is the subset I merged last week. Most of these are for the NXP i.MX platform (descriptions from their pull request): - Fix pcf2127 reset for imx7d-flex-concentrator board. - Fix i.MX6 suspend with Thumb-2 kernel. - Fix ethernet-phy address issue on imx6qdl-sr-som board. - Fix GPIO3 `gpio-ranges` on i.MX8MP. - Select SOC_BUS for IMX_SCU driver to fix build issue. - Fix backlight pwm on imx6qdl-kontron-samx6i which is lost from #pwm-cells conversion. - Fix duplicated bus node name for i.MX8MN SoC. - Fix reset register offset on LS1028A SoC. - Rename MMC node aliases for imx6q-tbs2910 to keep the MMC device index consistent with previous kernel version. - Selecting ARM_GIC_V3 on non-CP15 processors to fix one build failure with i.MX8M SoC driver. - Fix typos with status property on imx6qdl-kontron-samx6i board. - Fix duplicated regulator-name on imx6qdl-gw52xx board. Aside from i.MX, the bugfixes are all over the place: - Coccinelle found a refcount imbalance on integrator - defconfig fix for TI K3 - A boot regression fix for ST ux500 - A code preemption fix for the optee driver - USB DMA regression on Broadcom Stingray - A bogus boot time warning fix for at91 code" * tag 'arm-soc-fixes-v5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: MAINTAINERS: Include bcm2835 subsequents into search arm64: dts: broadcom: Fix USB DMA address translation for Stingray drivers: soc: atmel: add null entry at the end of at91_soc_allowed_list[] drivers: soc: atmel: Avoid calling at91_soc_init on non AT91 SoCs tee: optee: replace might_sleep with cond_resched firmware: imx: select SOC_BUS to fix firmware build arm64: dts: imx8mp: Correct the gpio ranges of gpio3 ARM: dts: imx6qdl-sr-som: fix some cubox-i platforms ARM: imx: build suspend-imx6.S with arm instruction set ARM: dts: imx7d-flex-concentrator: fix pcf2127 reset ARM: dts: ux500: Reserve memory carveouts arm64: defconfig: Drop unused K3 SoC specific options bus: arm-integrator-lm: Add of_node_put() before return statement ARM: dts: imx6qdl-gw52xx: fix duplicate regulator naming ARM: dts: imx6qdl-kontron-samx6i: fix i2c_lcd/cam default status ARM: imx: fix imx8m dependencies ARM: dts: tbs2910: rename MMC node aliases arm64: dts: ls1028a: fix the offset of the reset register arm64: dts: imx8mn: Fix duplicate node name ARM: dts: imx6qdl-kontron-samx6i: fix pwms for lcd-backlight
2021-01-28Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds12-34/+51
Pull rdma fixes from Jason Gunthorpe: "Several recent regressions and some bug fixes: - Typo corrupting the max_recv_sge for cxgb4 - Regression from re-using kernel enums as a HW AbI in vmw_pvrdma - Sleeping inside a spinlock in hns - Revert the attempt to fix devlink deadlocks as the fix is more buggy - Typo in sysfs_emit_at conversions - Revert the removal of VLAN support in rxe" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: Revert "RDMA/rxe: Remove VLAN code leftovers from RXE" RDMA/usnic: Fix misuse of sysfs_emit_at Revert "RDMA/mlx5: Fix devlink deadlock on net namespace deletion" RDMA/hns: Use mutex instead of spinlock for ida allocation RDMA/vmw_pvrdma: Fix network_hdr_type reported in WC RDMA/cxgb4: Fix the reported max_recv_sge value
2021-01-28Merge branch 'for-linus' of ↵Linus Torvalds3-5/+7
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - NULL pointer dereference regression fix for Wacom driver (Jason Gerecke) - functional regression fix for pam handling on some Elan and Synaptics touchpads (Kai-Heng Feng) * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: wacom: Correct NULL dereference on AES pen proximity HID: multitouch: Apply MT_QUIRK_CONFIDENCE quirk for multi-input devices
2021-01-28cifs: fix mounts to subdirectories of targetSteve French1-0/+1
The "prefixpath" mount option needs to be ignored which was missed in the recent conversion to the new mount API (prefixpath would be set by the mount helper if mounting a subdirectory of the root of a share e.g. //server/share/subdir) Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api") Suggested-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Steve French <[email protected]> Reviewed-by: Ronnie Sahlberg <[email protected]>
2021-01-28Merge tag 'media/v5.11-2' of ↵Linus Torvalds16-26/+22
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media Pull media fixes from Mauro Carvalho Chehab: - a V4L2 core regression at videobuf2 when checking for single-plane dmabuf - a change at uAPI header v4l2-subdev.h, fixing a breakage as BIT() macro is not available in userspace - fix some regressions at RC core due to the usage of microseconds everywhere on it - a fix for a race condition at RC core - a rename on a newly-introduced kAPI symbol (v4l2_get_link_rate), currently used only by a single driver - Regression fixes for rcar-vin, cedrus, ite-cir, hantro, css, venus, and cec drivers. * tag 'media/v5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: media: hantro: Fix reset_raw_fmt initialization media: cec: add stm32 driver media: cedrus: Fix H264 decoding media: v4l2-subdev.h: BIT() is not available in userspace media: Revert "media: videobuf2: Fix length check for single plane dmabuf queueing" media: rc: ite-cir: fix min_timeout calculation media: venus: core: Fix platform driver shutdown media: rc: fix timeout handling after switch to microsecond durations media: v4l: common: Fix naming of v4l2_get_link_rate media: rcar-vin: fix return, use ret instead of zero media: ccs: Get static data version minor correctly media: ccs-pll: Fix link frequency for C-PHY media: rc: ensure that uevent can be read directly after rc device register
2021-01-28Merge tag 'clk-fixes-for-linus' of ↵Linus Torvalds4-24/+9
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk fixes from Stephen Boyd: "A handful of clk driver fixes: - Build fix for CONFIG_PM=n in the mmp2 driver - Kconfig warning for unmet dependencies in the i.MX driver - Make the camera AHB clk always be enabled on qcom sc7180 - Use rate round down semantics for qcom sm8250 SD clks" * tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: clk: mmp2: fix build without CONFIG_PM clk: qcom: gcc-sm250: Use floor ops for sdcc clks clk: imx: fix Kconfig warning for i.MX SCU clk clk: qcom: gcc-sc7180: Mark the camera abh clock always ON
2021-01-28Merge tag 'sound-5.11-rc6' of ↵Linus Torvalds28-65/+204
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound fixes from Takashi Iwai: "Although the incoming fixes haven't settled down yet, all changes here are small and mostly device-specific fixes, so nothing look worrisome. - Yet another USB-audio regression fixes - HD-audio ID fix and device-specific quirks - SOF Intel / SoundWire fixes including topology - ASoC Qualcomm and Mediatek fixes" * tag 'sound-5.11-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (24 commits) ALSA: hda/via: Apply the workaround generically for Clevo machines ASoC: Intel: sof_sdw: set proper flags for Dell TGL-H SKU 0A5E ASoC: qcom: lpass: Fix out-of-bounds DAI ID lookup ASoC: mediatek: mt8192-mt6359: add format constraints for RT5682 ASoC: ak4458: correct reset polarity ASoC: SOF: SND_INTEL_DSP_CONFIG dependency ASoC: SOF: Intel: soundwire: fix select/depend unmet dependencies ALSA: hda: intel-dsp-config: add PCI id for TGL-H ALSA: usb-audio: workaround for iface reset issue ALSA: pcm: One more dependency for hw constraints ALSA: hda/realtek: Enable headset of ASUS B1400CEPE with ALC256 ASoC: Intel: Skylake: Zero snd_ctl_elem_value ASoC: Intel: Skylake: skl-topology: Fix OOPs ib skl_tplg_complete ASoC: qcom: Fix number of HDMI RDMA channels on sc7180 ASoC: mediatek: mt8183-da7219: ignore TDM DAI link by default ASoC: mediatek: mt8183-mt6358: ignore TDM DAI link by default ASoC: topology: Properly unregister DAI on removal ASoC: topology: Fix memory corruption in soc_tplg_denum_create_values() ASoC: qcom: lpass-ipq806x: fix bitwidth regmap field ASoC: AMD Renoir - refine DMI entries for some Lenovo products ...
2021-01-28Revert "mm/slub: fix a memory leak in sysfs_slab_add()"Wang Hai1-3/+1
This reverts commit dde3c6b72a16c2db826f54b2d49bdea26c3534a2. syzbot report a double-free bug. The following case can cause this bug. - mm/slab_common.c: create_cache(): if the __kmem_cache_create() fails, it does: out_free_cache: kmem_cache_free(kmem_cache, s); - but __kmem_cache_create() - at least for slub() - will have done sysfs_slab_add(s) -> sysfs_create_group() .. fails .. -> kobject_del(&s->kobj); .. which frees s ... We can't remove the kmem_cache_free() in create_cache(), because other error cases of __kmem_cache_create() do not free this. So, revert the commit dde3c6b72a16 ("mm/slub: fix a memory leak in sysfs_slab_add()") to fix this. Reported-by: [email protected] Fixes: dde3c6b72a16 ("mm/slub: fix a memory leak in sysfs_slab_add()") Acked-by: Vlastimil Babka <[email protected]> Signed-off-by: Wang Hai <[email protected]> Cc: <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2021-01-28cifs: ignore auto and noauto options if givenAdam Harvey1-0/+1
In 24e0a1eff9e2, the noauto and auto options were missed when migrating to the new mount API. As a result, users with noauto in their fstab mount options are now unable to mount cifs filesystems, as they'll receive an "Unknown parameter" error. This restores the old behaviour of ignoring noauto and auto if they're given. Fixes: 24e0a1eff9e2 ("cifs: switch to new mount api") Signed-off-by: Adam Harvey <[email protected]> Reviewed-by: Ronnie Sahlberg <[email protected]> Signed-off-by: Steve French <[email protected]>
2021-01-28bcache: only check feature sets when sb->version >= ↵Coly Li1-0/+6
BCACHE_SB_VERSION_CDEV_WITH_FEATURES For super block version < BCACHE_SB_VERSION_CDEV_WITH_FEATURES, it doesn't make sense to check the feature sets. This patch checks super block version in bch_has_feature_* routines, if the version doesn't have feature sets yet, returns 0 (false) to the caller. Fixes: 5342fd425502 ("bcache: set bcache device into read-only mode for BCH_FEATURE_INCOMPAT_OBSO_LARGE_BUCKET") Fixes: ffa470327572 ("bcache: add bucket_size_hi into struct cache_sb_disk for large bucket") Cc: [email protected] # 5.9+ Reported-and-tested-by: Bockholdt Arne <[email protected]> Signed-off-by: Coly Li <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-01-28block: fix bd_size_lock useDamien Le Moal2-4/+7
Some block device drivers, e.g. the skd driver, call set_capacity() with IRQ disabled. This results in lockdep ito complain about inconsistent lock states ("inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage") because set_capacity takes a block device bd_size_lock using the functions spin_lock() and spin_unlock(). Ensure a consistent locking state by replacing these calls with spin_lock_irqsave() and spin_lock_irqrestore(). The same applies to bdev_set_nr_sectors(). With this fix, all lockdep complaints are resolved. Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-01-28blk-cgroup: Use cond_resched() when destroy blkgsBaolin Wang1-5/+13
On !PREEMPT kernel, we can get below softlockup when doing stress testing with creating and destroying block cgroup repeatly. The reason is it may take a long time to acquire the queue's lock in the loop of blkcg_destroy_blkgs(), or the system can accumulate a huge number of blkgs in pathological cases. We can add a need_resched() check on each loop and release locks and do cond_resched() if true to avoid this issue, since the blkcg_destroy_blkgs() is not called from atomic contexts. [ 4757.010308] watchdog: BUG: soft lockup - CPU#11 stuck for 94s! [ 4757.010698] Call trace: [ 4757.010700]  blkcg_destroy_blkgs+0x68/0x150 [ 4757.010701]  cgwb_release_workfn+0x104/0x158 [ 4757.010702]  process_one_work+0x1bc/0x3f0 [ 4757.010704]  worker_thread+0x164/0x468 [ 4757.010705]  kthread+0x108/0x138 Suggested-by: Tejun Heo <[email protected]> Signed-off-by: Baolin Wang <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-01-28iommu/vt-d: Do not use flush-queue when caching-mode is onNadav Amit1-1/+31
When an Intel IOMMU is virtualized, and a physical device is passed-through to the VM, changes of the virtual IOMMU need to be propagated to the physical IOMMU. The hypervisor therefore needs to monitor PTE mappings in the IOMMU page-tables. Intel specifications provide "caching-mode" capability that a virtual IOMMU uses to report that the IOMMU is virtualized and a TLB flush is needed after mapping to allow the hypervisor to propagate virtual IOMMU mappings to the physical IOMMU. To the best of my knowledge no real physical IOMMU reports "caching-mode" as turned on. Synchronizing the virtual and the physical IOMMU tables is expensive if the hypervisor is unaware which PTEs have changed, as the hypervisor is required to walk all the virtualized tables and look for changes. Consequently, domain flushes are much more expensive than page-specific flushes on virtualized IOMMUs with passthrough devices. The kernel therefore exploited the "caching-mode" indication to avoid domain flushing and use page-specific flushing in virtualized environments. See commit 78d5f0f500e6 ("intel-iommu: Avoid global flushes with caching mode.") This behavior changed after commit 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing"). Now, when batched TLB flushing is used (the default), full TLB domain flushes are performed frequently, requiring the hypervisor to perform expensive synchronization between the virtual TLB and the physical one. Getting batched TLB flushes to use page-specific invalidations again in such circumstances is not easy, since the TLB invalidation scheme assumes that "full" domain TLB flushes are performed for scalability. Disable batched TLB flushes when caching-mode is on, as the performance benefit from using batched TLB invalidations is likely to be much smaller than the overhead of the virtual-to-physical IOMMU page-tables synchronization. Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing") Signed-off-by: Nadav Amit <[email protected]> Cc: David Woodhouse <[email protected]> Cc: Lu Baolu <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Will Deacon <[email protected]> Cc: [email protected] Acked-by: Lu Baolu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2021-01-28entry: Unbreak single step reporting behaviourYuxuan Shui1-1/+1
The move of TIF_SYSCALL_EMU to SYSCALL_WORK_SYSCALL_EMU broke single step reporting. The original code reported the single step when TIF_SINGLESTEP was set and TIF_SYSCALL_EMU was not set. The SYSCALL_WORK conversion got the logic wrong and now the reporting only happens when both bits are set. Restore the original behaviour. [ tglx: Massaged changelog and dropped the pointless double negation ] Fixes: 64eb35f701f0 ("ptrace: Migrate TIF_SYSCALL_EMU to use SYSCALL_WORK flag") Signed-off-by: Yuxuan Shui <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Reviewed-by: Gabriel Krisman Bertazi <[email protected]> Link: https://lore.kernel.org/r/877do3gaq9.fsf@m5Zedd9JOGzJrf0
2021-01-28iommu/vt-d: Correctly check addr alignment in qi_flush_dev_iotlb_pasid()Lu Baolu1-1/+1
An incorrect address mask is being used in the qi_flush_dev_iotlb_pasid() to check the address alignment. This leads to a lot of spurious kernel warnings: [ 485.837093] DMAR: Invalidate non-aligned address 7f76f47f9000, order 0 [ 485.837098] DMAR: Invalidate non-aligned address 7f76f47f9000, order 0 [ 492.494145] qi_flush_dev_iotlb_pasid: 5734 callbacks suppressed [ 492.494147] DMAR: Invalidate non-aligned address 7f7728800000, order 11 [ 492.508965] DMAR: Invalidate non-aligned address 7f7728800000, order 11 Fix it by checking the alignment in right way. Fixes: 288d08e780088 ("iommu/vt-d: Handle non-page aligned address") Reported-and-tested-by: Guo Kaijie <[email protected]> Signed-off-by: Lu Baolu <[email protected]> Cc: Liu Yi L <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2021-01-28iommu/amd: Use IVHD EFR for early initialization of IOMMU featuresSuravee Suthikulpanit3-7/+60
IOMMU Extended Feature Register (EFR) is used to communicate the supported features for each IOMMU to the IOMMU driver. This is normally read from the PCI MMIO register offset 0x30, and used by the iommu_feature() helper function. However, there are certain scenarios where the information is needed prior to PCI initialization, and the iommu_feature() function is used prematurely w/o warning. This has caused incorrect initialization of IOMMU. This is the case for the commit 6d39bdee238f ("iommu/amd: Enforce 4k mapping for certain IOMMU data structures") Since, the EFR is also available in the IVHD header, and is available to the driver prior to PCI initialization. Therefore, default to using the IVHD EFR instead. Fixes: 6d39bdee238f ("iommu/amd: Enforce 4k mapping for certain IOMMU data structures") Signed-off-by: Suravee Suthikulpanit <[email protected]> Tested-by: Brijesh Singh <[email protected]> Reviewed-by: Robert Richter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2021-01-28i2c: mediatek: Move suspend and resume handling to NOIRQ phaseQii Wang1-3/+16
Some i2c device driver indirectly uses I2C driver when it is now being suspended. The i2c devices driver is suspended during the NOIRQ phase and this cannot be changed due to other dependencies. Therefore, we also need to move the suspend handling for the I2C controller driver to the NOIRQ phase as well. Signed-off-by: Qii Wang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-01-27Merge tag 'mlx5-fixes-2021-01-26' of ↵Jakub Kicinski10-55/+114
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux Saeed Mahameed says: ==================== mlx5 fixes 2021-01-26 This series introduces some fixes to mlx5 driver. * tag 'mlx5-fixes-2021-01-26' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5: CT: Fix incorrect removal of tuple_nat_node from nat rhashtable net/mlx5e: Revert parameters on errors when changing MTU and LRO state without reset net/mlx5e: Revert parameters on errors when changing trust state without reset net/mlx5e: Correctly handle changing the number of queues when the interface is down net/mlx5e: Fix CT rule + encap slow path offload and deletion net/mlx5e: Disable hw-tc-offload when MLX5_CLS_ACT config is disabled net/mlx5: Maintain separate page trees for ECPF and PF functions net/mlx5e: Fix IPSEC stats net/mlx5e: Reduce tc unsupported key print level net/mlx5e: free page before return net/mlx5e: E-switch, Fix rate calculation for overflow net/mlx5: Fix memory leak on flow table creation error flow ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-27ibmvnic: Ensure that CRQ entry read are correctly orderedLijun Pan1-0/+6
Ensure that received Command-Response Queue (CRQ) entries are properly read in order by the driver. dma_rmb barrier has been added before accessing the CRQ descriptor to ensure the entire descriptor is read before processing. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Lijun Pan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-27Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfJakub Kicinski3-18/+30
Pablo Neira Ayuso says: ==================== Netfilter fixes for net 1) Honor stateful expressions defined in the set from the dynset extension. The set definition provides a stateful expression that must be used by the dynset expression in case it is specified. 2) Missing timeout extension in the set element in the dynset extension leads to inconsistent ruleset listing, not allowing the user to restore timeout and expiration on ruleset reload. 3) Do not dump the stateful expression from the dynset extension if it coming from the set definition. * git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf: netfilter: nft_dynset: dump expressions when set definition contains no expressions netfilter: nft_dynset: add timeout extension to template netfilter: nft_dynset: honor stateful expressions in set definition ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-27Merge tag 'linux-can-fixes-for-5.11-20210127' of ↵Jakub Kicinski1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-01-27 The patch is by Dan Carpenter and fixes a potential information leak in can_fill_info(). * tag 'linux-can-fixes-for-5.11-20210127' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: dev: prevent potential information leak in can_fill_info() ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-27MAINTAINERS: add missing header for bondingJakub Kicinski1-0/+1
include/net/bonding.h is missing from bonding entry. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-27Merge branch '100GbE' of ↵Jakub Kicinski8-34/+60
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Anthony Nguyen says: ==================== Intel Wired LAN Driver Updates 2021-01-26 This series contains updates to the ice, i40e, and igc driver. Henry corrects setting an unspecified protocol to IPPROTO_NONE instead of 0 for IPv6 flexbytes filters for ice. Nick fixes the IPv6 extension header being processed incorrectly and updates the netdev->dev_addr if it exists in hardware as it may have been modified outside the ice driver. Brett ensures a user cannot request more channels than available LAN MSI-X and fixes the minimum allocation logic as it was incorrectly trying to use more MSI-X than allocated for ice. Stefan Assmann minimizes the delay between getting and using the VSI pointer to prevent a possible crash for i40e. Corinna Vinschen fixes link speed advertising for igc. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: igc: fix link speed advertising i40e: acquire VSI pointer only after VF is initialized ice: Fix MSI-X vector fallback logic ice: Don't allow more channels than LAN MSI-X available ice: update dev_addr in ice_set_mac_address even if HW filter exists ice: Implement flow for IPv6 next header (extension header) ice: fix FDir IPv6 flexbyte ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-27net: decnet: fix netdev refcount leaking on error pathVadim Fedorenko1-1/+1
On building the route there is an assumption that the destination could be local. In this case loopback_dev is used to get the address. If the address is still cannot be retrieved dn_route_output_slow returns EADDRNOTAVAIL with loopback_dev reference taken. Cannot find hash for the fixes tag because this code was introduced long time ago. I don't think that this bug has ever fired but the patch is done just to have a consistent code base. Signed-off-by: Vadim Fedorenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-27net: switchdev: don't set port_obj_info->handled true when -EOPNOTSUPPRasmus Villemoes1-10/+13
It's not true that switchdev_port_obj_notify() only inspects the ->handled field of "struct switchdev_notifier_port_obj_info" if call_switchdev_blocking_notifiers() returns 0 - there's a WARN_ON() triggering for a non-zero return combined with ->handled not being true. But the real problem here is that -EOPNOTSUPP is not being properly handled. The wrapper functions switchdev_handle_port_obj_add() et al change a return value of -EOPNOTSUPP to 0, and the treatment of ->handled in switchdev_port_obj_notify() seems to be designed to change that back to -EOPNOTSUPP in case nobody actually acted on the notifier (i.e., everybody returned -EOPNOTSUPP). Currently, as soon as some device down the stack passes the check_cb() check, ->handled gets set to true, which means that switchdev_port_obj_notify() cannot actually ever return -EOPNOTSUPP. This, for example, means that the detection of hardware offload support in the MRP code is broken: switchdev_port_obj_add() used by br_mrp_switchdev_send_ring_test() always returns 0, so since the MRP code thinks the generation of MRP test frames has been offloaded, no such frames are actually put on the wire. Similarly, br_mrp_switchdev_set_ring_role() also always returns 0, causing mrp->ring_role_offloaded to be set to 1. To fix this, continue to set ->handled true if any callback returns success or any error distinct from -EOPNOTSUPP. But if all the callbacks return -EOPNOTSUPP, make sure that ->handled stays false, so the logic in switchdev_port_obj_notify() can propagate that information. Fixes: 9a9f26e8f7ea ("bridge: mrp: Connect MRP API with the switchdev API") Fixes: f30f0601eb93 ("switchdev: Add helpers to aid traversal through lower devices") Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-27of/device: Update dma_range_map only when dev has valid dma-rangesYong Wu1-3/+7
The commit e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") always update dma_range_map even though it was already set, like in the sunxi_mbus driver. the issue is reported at [1]. This patch avoid this(Updating it only when dev has valid dma-ranges). Meanwhile, dma_range_map contains the devices' dma_ranges information, This patch moves dma_range_map before of_iommu_configure. The iommu driver may need to know the dma_address requirements of its iommu consumer devices. [1] https://lore.kernel.org/linux-arm-kernel/[email protected]/ CC: Frank Rowand <[email protected]> Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset"), Suggested-by: Robin Murphy <[email protected]> Signed-off-by: Yong Wu <[email protected]> Signed-off-by: Paul Kocialkowski <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Signed-off-by: Rob Herring <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-01-27Merge branch 'parisc-5.11-2' of ↵Linus Torvalds3-9/+12
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fixes from Helge Deller: "Two small fixes: - Fix linking error with 64-bit kernel when modules are disabled, reported by kernel test robot - Remove leftover reference to power_tasklet, by Davidlohr Bueso" * 'parisc-5.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: Enable -mlong-calls gcc option by default when !CONFIG_MODULES parisc: Remove leftover reference to the power_tasklet
2021-01-27io_uring: fix flush cqring overflow list while TASK_INTERRUPTIBLEHao Xu1-2/+6
Abaci reported the follow warning: [ 27.073425] do not call blocking ops when !TASK_RUNNING; state=1 set at [] prepare_to_wait_exclusive+0x3a/0xc0 [ 27.075805] WARNING: CPU: 0 PID: 951 at kernel/sched/core.c:7853 __might_sleep+0x80/0xa0 [ 27.077604] Modules linked in: [ 27.078379] CPU: 0 PID: 951 Comm: a.out Not tainted 5.11.0-rc3+ #1 [ 27.079637] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 27.080852] RIP: 0010:__might_sleep+0x80/0xa0 [ 27.081835] Code: 65 48 8b 04 25 80 71 01 00 48 8b 90 c0 15 00 00 48 8b 70 18 48 c7 c7 08 39 95 82 c6 05 f9 5f de 08 01 48 89 d1 e8 00 c6 fa ff 0b eb bf 41 0f b6 f5 48 c7 c7 40 23 c9 82 e8 f3 48 ec 00 eb a7 [ 27.084521] RSP: 0018:ffffc90000fe3ce8 EFLAGS: 00010286 [ 27.085350] RAX: 0000000000000000 RBX: ffffffff82956083 RCX: 0000000000000000 [ 27.086348] RDX: ffff8881057a0000 RSI: ffffffff8118cc9e RDI: ffff88813bc28570 [ 27.087598] RBP: 00000000000003a7 R08: 0000000000000001 R09: 0000000000000001 [ 27.088819] R10: ffffc90000fe3e00 R11: 00000000fffef9f0 R12: 0000000000000000 [ 27.089819] R13: 0000000000000000 R14: ffff88810576eb80 R15: ffff88810576e800 [ 27.091058] FS: 00007f7b144cf740(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 27.092775] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.093796] CR2: 00000000022da7b8 CR3: 000000010b928002 CR4: 00000000003706f0 [ 27.094778] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 27.095780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 27.097011] Call Trace: [ 27.097685] __mutex_lock+0x5d/0xa30 [ 27.098565] ? prepare_to_wait_exclusive+0x71/0xc0 [ 27.099412] ? io_cqring_overflow_flush.part.101+0x6d/0x70 [ 27.100441] ? lockdep_hardirqs_on_prepare+0xe9/0x1c0 [ 27.101537] ? _raw_spin_unlock_irqrestore+0x2d/0x40 [ 27.102656] ? trace_hardirqs_on+0x46/0x110 [ 27.103459] ? io_cqring_overflow_flush.part.101+0x6d/0x70 [ 27.104317] io_cqring_overflow_flush.part.101+0x6d/0x70 [ 27.105113] io_cqring_wait+0x36e/0x4d0 [ 27.105770] ? find_held_lock+0x28/0xb0 [ 27.106370] ? io_uring_remove_task_files+0xa0/0xa0 [ 27.107076] __x64_sys_io_uring_enter+0x4fb/0x640 [ 27.107801] ? rcu_read_lock_sched_held+0x59/0xa0 [ 27.108562] ? lockdep_hardirqs_on_prepare+0xe9/0x1c0 [ 27.109684] ? syscall_enter_from_user_mode+0x26/0x70 [ 27.110731] do_syscall_64+0x2d/0x40 [ 27.111296] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 27.112056] RIP: 0033:0x7f7b13dc8239 [ 27.112663] Code: 01 00 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 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 3d 01 f0 ff ff 73 01 c3 48 8b 0d 27 ec 2c 00 f7 d8 64 89 01 48 [ 27.115113] RSP: 002b:00007ffd6d7f5c88 EFLAGS: 00000286 ORIG_RAX: 00000000000001aa [ 27.116562] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7b13dc8239 [ 27.117961] RDX: 000000000000478e RSI: 0000000000000000 RDI: 0000000000000003 [ 27.118925] RBP: 00007ffd6d7f5cb0 R08: 0000000020000040 R09: 0000000000000008 [ 27.119773] R10: 0000000000000001 R11: 0000000000000286 R12: 0000000000400480 [ 27.120614] R13: 00007ffd6d7f5d90 R14: 0000000000000000 R15: 0000000000000000 [ 27.121490] irq event stamp: 5635 [ 27.121946] hardirqs last enabled at (5643): [] console_unlock+0x5c4/0x740 [ 27.123476] hardirqs last disabled at (5652): [] console_unlock+0x4e7/0x740 [ 27.125192] softirqs last enabled at (5272): [] __do_softirq+0x3c5/0x5aa [ 27.126430] softirqs last disabled at (5267): [] asm_call_irq_on_stack+0xf/0x20 [ 27.127634] ---[ end trace 289d7e28fa60f928 ]--- This is caused by calling io_cqring_overflow_flush() which may sleep after calling prepare_to_wait_exclusive() which set task state to TASK_INTERRUPTIBLE Reported-by: Abaci <[email protected]> Fixes: 6c503150ae33 ("io_uring: patch up IOPOLL overflow_flush sync") Reviewed-by: Pavel Begunkov <[email protected]> Signed-off-by: Hao Xu <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-01-27Revert "block: simplify set_init_blocksize" to regain lost performanceMaxim Mikityanskiy1-1/+9
The cited commit introduced a serious regression with SATA write speed, as found by bisecting. This patch reverts this commit, which restores write speed back to the values observed before this commit. The performance tests were done on a Helios4 NAS (2nd batch) with 4 HDDs (WD8003FFBX) using dd (bs=1M count=2000). "Direct" is a test with a single HDD, the rest are different RAID levels built over the first partitions of 4 HDDs. Test results are in MB/s, R is read, W is write. | Direct | RAID0 | RAID10 f2 | RAID10 n2 | RAID6 ----------------+--------+-------+-----------+-----------+-------- 9011495c9466 | R:256 | R:313 | R:276 | R:313 | R:323 (before faulty) | W:254 | W:253 | W:195 | W:204 | W:117 ----------------+--------+-------+-----------+-----------+-------- 5ff9f19231a0 | R:257 | R:398 | R:312 | R:344 | R:391 (faulty commit) | W:154 | W:122 | W:67.7 | W:66.6 | W:67.2 ----------------+--------+-------+-----------+-----------+-------- 5.10.10 | R:256 | R:401 | R:312 | R:356 | R:375 unpatched | W:149 | W:123 | W:64 | W:64.1 | W:61.5 ----------------+--------+-------+-----------+-----------+-------- 5.10.10 | R:255 | R:396 | R:312 | R:340 | R:393 patched | W:247 | W:274 | W:220 | W:225 | W:121 Applying this patch doesn't hurt read performance, while improves the write speed by 1.5x - 3.5x (more impact on RAID tests). The write speed is restored back to the state before the faulty commit, and even a bit higher in RAID tests (which aren't HDD-bound on this device) - that is likely related to other optimizations done between the faulty commit and 5.10.10 which also improved the read speed. Signed-off-by: Maxim Mikityanskiy <[email protected]> Fixes: 5ff9f19231a0 ("block: simplify set_init_blocksize") Cc: Christoph Hellwig <[email protected]> Cc: Jens Axboe <[email protected]> Acked-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-01-27x86/xen: avoid warning in Xen pv guest with CONFIG_AMD_MEM_ENCRYPT enabledJuergen Gross3-1/+16
When booting a kernel which has been built with CONFIG_AMD_MEM_ENCRYPT enabled as a Xen pv guest a warning is issued for each processor: [ 5.964347] ------------[ cut here ]------------ [ 5.968314] WARNING: CPU: 0 PID: 1 at /home/gross/linux/head/arch/x86/xen/enlighten_pv.c:660 get_trap_addr+0x59/0x90 [ 5.972321] Modules linked in: [ 5.976313] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 5.11.0-rc5-default #75 [ 5.980313] Hardware name: Dell Inc. OptiPlex 9020/0PC5F7, BIOS A05 12/05/2013 [ 5.984313] RIP: e030:get_trap_addr+0x59/0x90 [ 5.988313] Code: 42 10 83 f0 01 85 f6 74 04 84 c0 75 1d b8 01 00 00 00 c3 48 3d 00 80 83 82 72 08 48 3d 20 81 83 82 72 0c b8 01 00 00 00 eb db <0f> 0b 31 c0 c3 48 2d 00 80 83 82 48 ba 72 1c c7 71 1c c7 71 1c 48 [ 5.992313] RSP: e02b:ffffc90040033d38 EFLAGS: 00010202 [ 5.996313] RAX: 0000000000000001 RBX: ffffffff82a141d0 RCX: ffffffff8222ec38 [ 6.000312] RDX: ffffffff8222ec38 RSI: 0000000000000005 RDI: ffffc90040033d40 [ 6.004313] RBP: ffff8881003984a0 R08: 0000000000000007 R09: ffff888100398000 [ 6.008312] R10: 0000000000000007 R11: ffffc90040246000 R12: ffff8884082182a8 [ 6.012313] R13: 0000000000000100 R14: 000000000000001d R15: ffff8881003982d0 [ 6.016316] FS: 0000000000000000(0000) GS:ffff888408200000(0000) knlGS:0000000000000000 [ 6.020313] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.024313] CR2: ffffc900020ef000 CR3: 000000000220a000 CR4: 0000000000050660 [ 6.028314] Call Trace: [ 6.032313] cvt_gate_to_trap.part.7+0x3f/0x90 [ 6.036313] ? asm_exc_double_fault+0x30/0x30 [ 6.040313] xen_convert_trap_info+0x87/0xd0 [ 6.044313] xen_pv_cpu_up+0x17a/0x450 [ 6.048313] bringup_cpu+0x2b/0xc0 [ 6.052313] ? cpus_read_trylock+0x50/0x50 [ 6.056313] cpuhp_invoke_callback+0x80/0x4c0 [ 6.060313] _cpu_up+0xa7/0x140 [ 6.064313] cpu_up+0x98/0xd0 [ 6.068313] bringup_nonboot_cpus+0x4f/0x60 [ 6.072313] smp_init+0x26/0x79 [ 6.076313] kernel_init_freeable+0x103/0x258 [ 6.080313] ? rest_init+0xd0/0xd0 [ 6.084313] kernel_init+0xa/0x110 [ 6.088313] ret_from_fork+0x1f/0x30 [ 6.092313] ---[ end trace be9ecf17dceeb4f3 ]--- Reason is that there is no Xen pv trap entry for X86_TRAP_VC. Fix that by adding a generic trap handler for unknown traps and wire all unknown bare metal handlers to this generic handler, which will just crash the system in case such a trap will ever happen. Fixes: 0786138c78e793 ("x86/sev-es: Add a Runtime #VC Exception Handler") Cc: <[email protected]> # v5.10 Signed-off-by: Juergen Gross <[email protected]> Reviewed-by: Andrew Cooper <[email protected]> Signed-off-by: Juergen Gross <[email protected]>
2021-01-27ACPI/IORT: Do not blindly trust DMA masks from firmwareMoritz Fischer1-2/+12
Address issue observed on real world system with suboptimal IORT table where DMA masks of PCI devices would get set to 0 as result. iort_dma_setup() would query the root complex'/named component IORT entry for a DMA mask, and use that over the one the device has been configured with earlier. Ideally we want to use the minimum mask of what the IORT contains for the root complex and what the device was configured with. Fixes: 5ac65e8c8941 ("ACPI/IORT: Support address size limit for root complexes") Signed-off-by: Moritz Fischer <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Acked-by: Lorenzo Pieralisi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]>
2021-01-27s390: uv: Fix sysfs max number of VCPUs reportingJanosch Frank3-4/+4
The number reported by the query is N-1 and I think people reading the sysfs file would expect N instead. For users creating VMs there's no actual difference because KVM's limit is currently below the UV's limit. Signed-off-by: Janosch Frank <[email protected]> Fixes: a0f60f8431999 ("s390/protvirt: Add sysfs firmware interface for Ultravisor information") Cc: [email protected] Reviewed-by: Claudio Imbrenda <[email protected]> Acked-by: Cornelia Huck <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-01-27s390/vfio-ap: No need to disable IRQ after queue resetTony Krowiak3-49/+69
The queues assigned to a matrix mediated device are currently reset when: * The VFIO_DEVICE_RESET ioctl is invoked * The mdev fd is closed by userspace (QEMU) * The mdev is removed from sysfs. Immediately after the reset of a queue, a call is made to disable interrupts for the queue. This is entirely unnecessary because the reset of a queue disables interrupts, so this will be removed. Furthermore, vfio_ap_irq_disable() does an unconditional PQAP/AQIC which can result in a specification exception (when the corresponding facility is not available), so this is actually a bugfix. Signed-off-by: Tony Krowiak <[email protected]> [[email protected]: minor rework before merging] Signed-off-by: Halil Pasic <[email protected]> Fixes: ec89b55e3bce ("s390: ap: implement PAPQ AQIC interception in kernel") Cc: <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-01-27s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidatedTony Krowiak1-21/+28
The vfio_ap device driver registers a group notifier with VFIO when the file descriptor for a VFIO mediated device for a KVM guest is opened to receive notification that the KVM pointer is set (VFIO_GROUP_NOTIFY_SET_KVM event). When the KVM pointer is set, the vfio_ap driver takes the following actions: 1. Stashes the KVM pointer in the vfio_ap_mdev struct that holds the state of the mediated device. 2. Calls the kvm_get_kvm() function to increment its reference counter. 3. Sets the function pointer to the function that handles interception of the instruction that enables/disables interrupt processing. 4. Sets the masks in the KVM guest's CRYCB to pass AP resources through to the guest. In order to avoid memory leaks, when the notifier is called to receive notification that the KVM pointer has been set to NULL, the vfio_ap device driver should reverse the actions taken when the KVM pointer was set. Fixes: 258287c994de ("s390: vfio-ap: implement mediated device open callback") Signed-off-by: Tony Krowiak <[email protected]> Reviewed-by: Halil Pasic <[email protected]> Reviewed-by: Cornelia Huck <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Christian Borntraeger <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]>
2021-01-27can: dev: prevent potential information leak in can_fill_info()Dan Carpenter1-1/+1
The "bec" struct isn't necessarily always initialized. For example, the mcp251xfd_get_berr_counter() function doesn't initialize anything if the interface is down. Fixes: 52c793f24054 ("can: netlink support for bus-error reporting and counters") Link: https://lore.kernel.org/r/YAkaRdRJncsJO8Ve@mwanda Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Marc Kleine-Budde <[email protected]>
2021-01-27rtc: mc146818: Detect and handle broken RTCsThomas Gleixner2-0/+15
The recent fix for handling the UIP bit unearthed another issue in the RTC code. If the RTC is advertised but the readout is straight 0xFF because it's not available, the old code just proceeded with crappy values, but the new code hangs because it waits for the UIP bit to become low. Add a sanity check in the RTC CMOS probe function which reads the RTC_VALID register (Register D) which should have bit 0-6 cleared. If that's not the case then fail to register the CMOS. Add the same check to mc146818_get_time(), warn once when the condition is true and invalidate the rtc_time data. Reported-by: Mickaël Salaün <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Mickaël Salaün <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-01-27xen: Fix XenStore initialisation for XS_LOCALDavid Woodhouse1-0/+31
In commit 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI") I reworked the triggering of xenbus_probe(). I tried to simplify things by taking out the workqueue based startup triggered from wake_waiting(); the somewhat poorly named xenbus IRQ handler. I missed the fact that in the XS_LOCAL case (Dom0 starting its own xenstored or xenstore-stubdom, which happens after the kernel is booted completely), that IRQ-based trigger is still actually needed. So... put it back, except more cleanly. By just spawning a xenbus_probe thread which waits on xb_waitq and runs the probe the first time it gets woken, just as the workqueue-based hack did. This is actually a nicer approach for *all* the back ends with different interrupt methods, and we can switch them all over to that without the complex conditions for when to trigger it. But not in -rc6. This is the minimal fix for the regression, although it's a step in the right direction instead of doing a partial revert and actually putting the workqueue back. It's also simpler than the workqueue. Fixes: 3499ba8198ca ("xen: Fix event channel callback via INTX/GSI") Reported-by: Juergen Gross <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Juergen Gross <[email protected]>
2021-01-26io_uring: fix wqe->lock/completion_lock deadlockPavel Begunkov1-8/+2
Joseph reports following deadlock: CPU0: ... io_kill_linked_timeout // &ctx->completion_lock io_commit_cqring __io_queue_deferred __io_queue_async_work io_wq_enqueue io_wqe_enqueue // &wqe->lock CPU1: ... __io_uring_files_cancel io_wq_cancel_cb io_wqe_cancel_pending_work // &wqe->lock io_cancel_task_cb // &ctx->completion_lock Only __io_queue_deferred() calls queue_async_work() while holding ctx->completion_lock, enqueue drained requests via io_req_task_queue() instead. Cc: [email protected] # 5.9+ Reported-by: Joseph Qi <[email protected]> Tested-by: Joseph Qi <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-01-26Merge branch 'net-fec-fix-temporary-rmii-clock-reset-on-link-up'Jakub Kicinski2-2/+9
Laurent Badel says: ==================== net: fec: Fix temporary RMII clock reset on link up v2: fixed a compilation warning The FEC drivers performs a "hardware reset" of the MAC module when the link is reported to be up. This causes a short glitch in the RMII clock due to the hardware reset clearing the receive control register which controls the MII mode. It seems that some link partners do not tolerate this glitch, and invalidate the link, which leads to a never-ending loop of negotiation-link up-link down events. This was observed with the iMX28 Soc and LAN8720/LAN8742 PHYs, with two Intel adapters I218-LM and X722-DA2 as link partners, though a number of other link partners do not seem to mind the clock glitch. Changing the hardware reset to a software reset (clearing bit 1 of the ECR register) cured the issue. Attempts to optimize fec_restart() in order to minimize the duration of the glitch were unsuccessful. Furthermore manually producing the glitch by setting MII mode and then back to RMII in two consecutive instructions, resulting in a clock glitch <10us in duration, was enough to cause the partner to invalidate the link. This strongly suggests that the root cause of the link being dropped is indeed the change in clock frequency. In an effort to minimize changes to driver, the patch proposes to use soft reset only for tested SoCs (iMX28) and only if the link is up. This preserves hardware reset in other situations, which might be required for proper setup of the MAC. ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26net: fec: Fix temporary RMII clock reset on link upLaurent Badel2-2/+9
fec_restart() does a hard reset of the MAC module when the link status changes to up. This temporarily resets the R_CNTRL register which controls the MII mode of the ENET_OUT clock. In the case of RMII, the clock frequency momentarily drops from 50MHz to 25MHz until the register is reconfigured. Some link partners do not tolerate this glitch and invalidate the link causing failure to establish a stable link when using PHY polling mode. Since as per IEEE802.3 the criteria for link validity are PHY-specific, what the partner should tolerate cannot be assumed, so avoid resetting the MII clock by using software reset instead of hardware reset when the link is up. This is generally relevant only if the SoC provides the clock to an external PHY and the PHY is configured for RMII. Signed-off-by: Laurent Badel <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26net: lapb: Add locking to the lapb moduleXie He3-20/+82
In the lapb module, the timers may run concurrently with other code in this module, and there is currently no locking to prevent the code from racing on "struct lapb_cb". This patch adds locking to prevent racing. 1. Add "spinlock_t lock" to "struct lapb_cb"; Add "spin_lock_bh" and "spin_unlock_bh" to APIs, timer functions and notifier functions. 2. Add "bool t1timer_stop, t2timer_stop" to "struct lapb_cb" to make us able to ask running timers to abort; Modify "lapb_stop_t1timer" and "lapb_stop_t2timer" to make them able to abort running timers; Modify "lapb_t2timer_expiry" and "lapb_t1timer_expiry" to make them abort after they are stopped by "lapb_stop_t1timer", "lapb_stop_t2timer", and "lapb_start_t1timer", "lapb_start_t2timer". 3. Let lapb_unregister wait for other API functions and running timers to stop. 4. The lapb_device_event function calls lapb_disconnect_request. In order to avoid trying to hold the lock twice, add a new function named "__lapb_disconnect_request" which assumes the lock is held, and make it called by lapb_disconnect_request and lapb_device_event. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: Martin Schiller <[email protected]> Signed-off-by: Xie He <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26ARM: zImage: atags_to_fdt: Fix node names on added root nodesRob Herring1-1/+2
Commit 7536c7e03e74 ("of/fdt: Remove redundant kbasename function call") exposed a bug creating DT nodes in the ATAGS to DT fixup code. Non-existent nodes would mistaken get created with a leading '/'. The problem was fdt_path_offset() takes a full path while creating a node with fdt_add_subnode() takes just the basename. Since this we only add root child nodes, we can just skip over the '/'. Fixes: 7536c7e03e74 ("of/fdt: Remove redundant kbasename function call") Reported-by: Chris Packham <[email protected]> Cc: Qi Zheng <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Rob Herring <[email protected]> Tested-by: Chris Packham <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2021-01-26team: protect features update by RCU to avoid deadlockIvan Vecera1-3/+3
Function __team_compute_features() is protected by team->lock mutex when it is called from team_compute_features() used when features of an underlying device is changed. This causes a deadlock when NETDEV_FEAT_CHANGE notifier for underlying device is fired due to change propagated from team driver (e.g. MTU change). It's because callbacks like team_change_mtu() or team_vlan_rx_{add,del}_vid() protect their port list traversal by team->lock mutex. Example (r8169 case where this driver disables TSO for certain MTU values): ... [ 6391.348202] __mutex_lock.isra.6+0x2d0/0x4a0 [ 6391.358602] team_device_event+0x9d/0x160 [team] [ 6391.363756] notifier_call_chain+0x47/0x70 [ 6391.368329] netdev_update_features+0x56/0x60 [ 6391.373207] rtl8169_change_mtu+0x14/0x50 [r8169] [ 6391.378457] dev_set_mtu_ext+0xe1/0x1d0 [ 6391.387022] dev_set_mtu+0x52/0x90 [ 6391.390820] team_change_mtu+0x64/0xf0 [team] [ 6391.395683] dev_set_mtu_ext+0xe1/0x1d0 [ 6391.399963] do_setlink+0x231/0xf50 ... In fact team_compute_features() called from team_device_event() does not need to be protected by team->lock mutex and rcu_read_lock() is sufficient there for port list traversal. Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device") Cc: Saeed Mahameed <[email protected]> Signed-off-by: Ivan Vecera <[email protected]> Reviewed-by: Cong Wang <[email protected]> Reviewed-by: Jiri Pirko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26MAINTAINERS: add David Ahern to IPv4/IPv6 maintainersJakub Kicinski1-0/+1
David has been the de-facto maintainer for much of the IP code for the last couple of years, let's make it official. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2021-01-26net/mlx5: CT: Fix incorrect removal of tuple_nat_node from nat rhashtablePaul Blakey1-7/+13
If a non nat tuple entry is inserted just to the regular tuples rhashtable (ct_tuples_ht) and not to natted tuples rhashtable (ct_nat_tuples_ht). Commit bc562be9674b ("net/mlx5e: CT: Save ct entries tuples in hashtables") mixed up the return labels and names sot that on cleanup or failure we still try to remove for the natted tuples rhashtable. Fix that by correctly checking if a natted tuples insertion before removing it. While here make it more readable. Fixes: bc562be9674b ("net/mlx5e: CT: Save ct entries tuples in hashtables") Reviewed-by: Roi Dayan <[email protected]> Signed-off-by: Paul Blakey <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: Revert parameters on errors when changing MTU and LRO state ↵Maxim Mikityanskiy1-9/+21
without reset Sometimes, channel params are changed without recreating the channels. It happens in two basic cases: when the channels are closed, and when the parameter being changed doesn't affect how channels are configured. Such changes invoke a hardware command that might fail. The whole operation should be reverted in such cases, but the code that restores the parameters' values in the driver was missing. This commit adds this handling. Fixes: 2e20a151205b ("net/mlx5e: Fail safe mtu and lro setting") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
2021-01-26net/mlx5e: Revert parameters on errors when changing trust state without resetMaxim Mikityanskiy1-5/+8
Trust state may be changed without recreating the channels. It happens when the channels are closed, and when channel parameters (min inline mode) stay the same after changing the trust state. Changing the trust state is a hardware command that may fail. The current code didn't restore the channel parameters to their old values if an error happened and the channels were closed. This commit adds handling for this case. Fixes: 6e0504c69811 ("net/mlx5e: Change inline mode correctly when changing trust state") Signed-off-by: Maxim Mikityanskiy <[email protected]> Reviewed-by: Tariq Toukan <[email protected]> Signed-off-by: Saeed Mahameed <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.