aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-03-18Merge branch 'octeontx2-fixes'David S. Miller9-30/+65
Hariprasad Kelam says: ==================== octeontx2: miscellaneous fixes This series of patches fixes various issues related to NPC MCAM entry management, debugfs, devlink, CGX LMAC mapping, RSS config etc Change-log: v2: Fixed below review comments - corrected Fixed tag syntax with 12 digits SHA1 and providing space between SHA1 and subject line - remove code improvement patch - make commit description more clear ==================== Signed-off-by: David S. Miller <[email protected]>
2021-03-18octeontx2-af: Fix uninitialized variable warningSubbaraya Sundeep1-1/+1
Initialize l4_key_offset variable to fix uninitialized variable compiler warning. Fixes: b9b7421a01d8 ("octeontx2-af: Support ESP/AH RSS hashing") Signed-off-by: Subbaraya Sundeep <[email protected]> Signed-off-by: Hariprasad Kelam <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18octeontx2-af: fix infinite loop in unmapping NPC counterHariprasad Kelam1-1/+1
unmapping npc counter works in a way by traversing all mcam entries to find which mcam rule is associated with counter. But loop cursor variable 'entry' is not incremented before checking next mcam entry which resulting in infinite loop. This in turn hogs the kworker thread forever and no other mbox message is processed by AF driver after that. Fix this by updating entry value before checking next mcam entry. Fixes: a958dd59f9ce ("octeontx2-af: Map or unmap NPC MCAM entry and counter") Signed-off-by: Hariprasad Kelam <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18octeontx2-pf: Clear RSS enable flag on interace downGeetha sowjanya1-0/+5
RSS configuration can not be get/set when interface is in down state as they required mbox communication. RSS enable flag status is used for set/get configuration. Current code do not clear the RSS enable flag on interface down which lead to mbox error while trying to set/get RSS configuration. Fixes: 85069e95e531 ("octeontx2-pf: Receive side scaling support") Signed-off-by: Geetha sowjanya <[email protected]> Signed-off-by: Hariprasad Kelam <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18octeontx2-af: Fix irq free in rvu teardownGeetha sowjanya1-2/+4
Current devlink code try to free already freed irqs as the irq_allocate flag is not cleared after free leading to kernel crash while removing rvu driver. The patch fixes the irq free sequence and clears the irq_allocate flag on free. Fixes: 7304ac4567bc ("octeontx2-af: Add mailbox IRQ and msg handlers") Signed-off-by: Geetha sowjanya <[email protected]> Signed-off-by: Hariprasad Kelam <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18octeontx2-af: Return correct CGX RX fifo sizeSubbaraya Sundeep3-6/+22
CGX receive buffer size is a constant value and cannot be read from CGX0 block always since CGX0 may not enabled everytime. Hence return CGX receive buffer size from first enabled CGX block instead of CGX0. Fixes: 6e54e1c5399a ("octeontx2-af: cn10K: MTU configuration") Signed-off-by: Subbaraya Sundeep <[email protected]> Signed-off-by: Hariprasad Kelam <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18octeontx2-af: Remove TOS field from MKEX TXSubbaraya Sundeep1-2/+0
The MKEX profile describes what packet fields need to be extracted from the input packet and how to place those packet fields in the output key for MCAM matching. The MKEX profile can be in a way where higher layer packet fields can overwrite lower layer packet fields in output MCAM Key. Hence MKEX profile is always ensured that there are no overlaps between any of the layers. But the commit 42006910b5ea ("octeontx2-af: cleanup KPU config data") introduced TX TOS field which overlaps with DMAC in MCAM key. This led to AF driver returning error when TX rule is installed with DMAC as match criteria since DMAC gets overwritten and cannot be supported. This patch fixes the issue by removing TOS field from MKEX TX profile. Fixes: 42006910b5ea ("octeontx2-af: cleanup KPU config data") Signed-off-by: Subbaraya Sundeep <[email protected]> Signed-off-by: Hariprasad Kelam <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18octeontx2-af: Formatting debugfs entry rsrc_alloc.Rakesh Babu1-17/+29
With the existing rsrc_alloc's format, there is misalignment for the pcifunc entries whose VF's index is a double digit. This patch fixes this. pcifunc NPA NIX0 NIX1 SSO GROUP SSOWS TIM CPT0 CPT1 REE0 REE1 PF0:VF0 8 5 PF0:VF1 9 3 PF0:VF10 18 10 PF0:VF11 19 8 PF0:VF12 20 11 PF0:VF13 21 9 PF0:VF14 22 12 PF0:VF15 23 10 PF1 0 0 Fixes: 23205e6d06d4 ("octeontx2-af: Dump current resource provisioning status") Signed-off-by: Rakesh Babu <[email protected]> Signed-off-by: Hariprasad Kelam <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18octeontx2-pf: Do not modify number of rulesSubbaraya Sundeep1-1/+3
In the ETHTOOL_GRXCLSRLALL ioctl ethtool uses below structure to read number of rules from the driver. struct ethtool_rxnfc { __u32 cmd; __u32 flow_type; __u64 data; struct ethtool_rx_flow_spec fs; union { __u32 rule_cnt; __u32 rss_context; }; __u32 rule_locs[0]; }; Driver must not modify rule_cnt member. But currently driver modifies it by modifying rss_context. Hence fix it by using a local variable. Fixes: 81a4362016e7 ("octeontx2-pf: Add RSS multi group support") Signed-off-by: Subbaraya Sundeep <[email protected]> Signed-off-by: Hariprasad Kelam <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18Merge tag 'for-5.12-rc3-tag' of ↵Linus Torvalds6-35/+103
git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux Pull btrfs fixes from David Sterba: "There are still regressions being found and fixed in the zoned mode and subpage code, the rest are fixes for bugs reported by users. Regressions: - subpage block support: - readahead works on the proper block size - fix last page zeroing - zoned mode: - linked list corruption for tree log Fixes: - qgroup leak after falloc failure - tree mod log and backref resolving: - extent buffer cloning race when resolving backrefs - pin deleted leaves with active tree mod log users - drop debugging flag from slab cache" * tag 'for-5.12-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux: btrfs: always pin deleted leaves when there are active tree mod log users btrfs: fix race when cloning extent buffer during rewind of an old root btrfs: fix slab cache flags for free space tree bitmap btrfs: subpage: make readahead work properly btrfs: subpage: fix wild pointer access during metadata read failure btrfs: zoned: fix linked list corruption after log root tree allocation failure btrfs: fix qgroup data rsv leak caused by falloc failure btrfs: track qgroup released data in own variable in insert_prealloc_file_extent btrfs: fix wrong offset to zero out range beyond i_size
2021-03-18btrfs: fix check_data_csum() error message for direct I/OOmar Sandoval1-5/+9
Commit 1dae796aabf6 ("btrfs: inode: sink parameter start and len to check_data_csum()") replaced the start parameter to check_data_csum() with page_offset(), but page_offset() is not meaningful for direct I/O pages. Bring back the start parameter. Fixes: 265d4ac03fdf ("btrfs: sink parameter start and len to check_data_csum") CC: [email protected] # 5.11+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Omar Sandoval <[email protected]> Signed-off-by: David Sterba <[email protected]>
2021-03-18Merge tag 'vfio-v5.12-rc4' of git://github.com/awilliam/linux-vfioLinus Torvalds4-12/+27
Pull VFIO fixes from Alex Williamson: - Fix 32-bit issue with new unmap-all flag (Steve Sistare) - Various Kconfig changes for better coverage (Jason Gunthorpe) - Fix to batch pinning support (Daniel Jordan) * tag 'vfio-v5.12-rc4' of git://github.com/awilliam/linux-vfio: vfio/type1: fix vaddr_get_pfns() return in vfio_pin_page_external() vfio: Depend on MMU ARM: amba: Allow some ARM_AMBA users to compile with COMPILE_TEST vfio-platform: Add COMPILE_TEST to VFIO_PLATFORM vfio: IOMMU_API should be selected vfio/type1: fix unmap all on ILP32
2021-03-18Merge tag 'xfs-5.12-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds5-54/+61
Pull xfs fixes from Darrick Wong: "A couple of minor corrections for the new idmapping functionality, and a fix for a theoretical hang that could occur if we decide to abort a mount after dirtying the quota inodes. Summary: - Fix quota accounting on creat() when id mapping is enabled - Actually reclaim dirty quota inodes when mount fails - Typo fixes for documentation - Restrict both bulkstat calls on idmapped/namespaced mounts" * tag 'xfs-5.12-fixes-3' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: also reject BULKSTAT_SINGLE in a mount user namespace docs: ABI: Fix the spelling oustanding to outstanding in the file sysfs-fs-xfs xfs: force log and push AIL to clear pinned inodes when aborting mount xfs: fix quota accounting when a mount is idmapped
2021-03-18netsec: restore phy power state after controller resetMian Yousaf Kaukab1-3/+6
Since commit 8e850f25b581 ("net: socionext: Stop PHY before resetting netsec") netsec_netdev_init() power downs phy before resetting the controller. However, the state is not restored once the reset is complete. As a result it is not possible to bring up network on a platform with Broadcom BCM5482 phy. Fix the issue by restoring phy power state after controller reset is complete. Fixes: 8e850f25b581 ("net: socionext: Stop PHY before resetting netsec") Cc: [email protected] Signed-off-by: Mian Yousaf Kaukab <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhostLinus Torvalds11-40/+37
Pull virtio fixes from Michael Tsirkin: "Some fixes and cleanups all over the place" * tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: vhost-vdpa: set v->config_ctx to NULL if eventfd_ctx_fdget() fails vhost-vdpa: fix use-after-free of v->config_ctx vhost: Fix vhost_vq_reset() vhost_vdpa: fix the missing irq_bypass_unregister_producer() invocation vdpa_sim: Skip typecasting from void* virtio: remove export for virtio_config_{enable, disable} virtio-mmio: Use to_virtio_mmio_device() to simply code vdpa: set the virtqueue num during register
2021-03-18ipv6: weaken the v4mapped source checkJakub Kicinski4-10/+15
This reverts commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3. Commit 6af1799aaf3f ("ipv6: drop incoming packets having a v4mapped source address") introduced an input check against v4mapped addresses. Use of such addresses on the wire is indeed questionable and not allowed on public Internet. As the commit pointed out https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 lists potential issues. Unfortunately there are applications which use v4mapped addresses, and breaking them is a clear regression. For example v4mapped addresses (or any semi-valid addresses, really) may be used for uni-direction event streams or packet export. Since the issue which sparked the addition of the check was with TCP and request_socks in particular push the check down to TCPv6 and DCCP. This restores the ability to receive UDPv6 packets with v4mapped address as the source. Keep using the IPSTATS_MIB_INHDRERRORS statistic to minimize the user-visible changes. Fixes: 6af1799aaf3f ("ipv6: drop incoming packets having a v4mapped source address") Reported-by: Sunyi Shao <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Acked-by: Mat Martineau <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2021-03-18x86/kvm: Fix broken irq restoration in kvm_waitWanpeng Li1-13/+10
After commit 997acaf6b4b59c (lockdep: report broken irq restoration), the guest splatting below during boot: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 1 PID: 169 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x26/0x30 Modules linked in: hid_generic usbhid hid CPU: 1 PID: 169 Comm: systemd-udevd Not tainted 5.11.0+ #25 RIP: 0010:warn_bogus_irq_restore+0x26/0x30 Call Trace: kvm_wait+0x76/0x90 __pv_queued_spin_lock_slowpath+0x285/0x2e0 do_raw_spin_lock+0xc9/0xd0 _raw_spin_lock+0x59/0x70 lockref_get_not_dead+0xf/0x50 __legitimize_path+0x31/0x60 legitimize_root+0x37/0x50 try_to_unlazy_next+0x7f/0x1d0 lookup_fast+0xb0/0x170 path_openat+0x165/0x9b0 do_filp_open+0x99/0x110 do_sys_openat2+0x1f1/0x2e0 do_sys_open+0x5c/0x80 __x64_sys_open+0x21/0x30 do_syscall_64+0x32/0x50 entry_SYSCALL_64_after_hwframe+0x44/0xae The new consistency checking, expects local_irq_save() and local_irq_restore() to be paired and sanely nested, and therefore expects local_irq_restore() to be called with irqs disabled. The irqflags handling in kvm_wait() which ends up doing: local_irq_save(flags); safe_halt(); local_irq_restore(flags); instead triggers it. This patch fixes it by using local_irq_disable()/enable() directly. Cc: Thomas Gleixner <[email protected]> Reported-by: Dmitry Vyukov <[email protected]> Signed-off-by: Wanpeng Li <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-18KVM: X86: Fix missing local pCPU when executing wbinvd on all dirty pCPUsWanpeng Li1-1/+1
In order to deal with noncoherent DMA, we should execute wbinvd on all dirty pCPUs when guest wbinvd exits to maintain data consistency. smp_call_function_many() does not execute the provided function on the local core, therefore replace it by on_each_cpu_mask(). Reported-by: Nadav Amit <[email protected]> Cc: Nadav Amit <[email protected]> Signed-off-by: Wanpeng Li <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-18KVM: x86: Protect userspace MSR filter with SRCU, and set atomically-ishSean Christopherson3-54/+78
Fix a plethora of issues with MSR filtering by installing the resulting filter as an atomic bundle instead of updating the live filter one range at a time. The KVM_X86_SET_MSR_FILTER ioctl() isn't truly atomic, as the hardware MSR bitmaps won't be updated until the next VM-Enter, but the relevant software struct is atomically updated, which is what KVM really needs. Similar to the approach used for modifying memslots, make arch.msr_filter a SRCU-protected pointer, do all the work configuring the new filter outside of kvm->lock, and then acquire kvm->lock only when the new filter has been vetted and created. That way vCPU readers either see the old filter or the new filter in their entirety, not some half-baked state. Yuan Yao pointed out a use-after-free in ksm_msr_allowed() due to a TOCTOU bug, but that's just the tip of the iceberg... - Nothing is __rcu annotated, making it nigh impossible to audit the code for correctness. - kvm_add_msr_filter() has an unpaired smp_wmb(). Violation of kernel coding style aside, the lack of a smb_rmb() anywhere casts all code into doubt. - kvm_clear_msr_filter() has a double free TOCTOU bug, as it grabs count before taking the lock. - kvm_clear_msr_filter() also has memory leak due to the same TOCTOU bug. The entire approach of updating the live filter is also flawed. While installing a new filter is inherently racy if vCPUs are running, fixing the above issues also makes it trivial to ensure certain behavior is deterministic, e.g. KVM can provide deterministic behavior for MSRs with identical settings in the old and new filters. An atomic update of the filter also prevents KVM from getting into a half-baked state, e.g. if installing a filter fails, the existing approach would leave the filter in a half-baked state, having already committed whatever bits of the filter were already processed. [*] https://lkml.kernel.org/r/[email protected] Fixes: 1a155254ff93 ("KVM: x86: Introduce MSR filtering") Cc: [email protected] Cc: Alexander Graf <[email protected]> Reported-by: Yuan Yao <[email protected]> Signed-off-by: Sean Christopherson <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-18selftests: kvm: add set_boot_cpu_id testEmanuele Giuseppe Esposito3-0/+168
Test for the KVM_SET_BOOT_CPU_ID ioctl. Check that it correctly allows to change the BSP vcpu. Signed-off-by: Emanuele Giuseppe Esposito <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-18selftests: kvm: add _vm_ioctlEmanuele Giuseppe Esposito2-1/+7
As in kvm_ioctl and _kvm_ioctl, add the respective _vm_ioctl for vm_ioctl. _vm_ioctl invokes an ioctl using the vm fd, leaving the caller to test the result. Signed-off-by: Emanuele Giuseppe Esposito <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-18Merge branch 'iomap-5.12-fixes' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds1-0/+10
Pull iomap fix from Darrick Wong: "A single fix to the iomap code which fixes some drama when someone gives us a {de,ma}liciously fragmented swap file" * 'iomap-5.12-fixes' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: iomap: Fix negative assignment to unsigned sis->pages in iomap_swapfile_activate
2021-03-18selftests: kvm: add get_msr_index_featuresEmanuele Giuseppe Esposito5-2/+137
Test the KVM_GET_MSR_FEATURE_INDEX_LIST and KVM_GET_MSR_INDEX_LIST ioctls. Signed-off-by: Emanuele Giuseppe Esposito <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-18workqueue/tracing: Copy workqueue name to buffer in trace eventSteven Rostedt (VMware)1-3/+3
The trace event "workqueue_queue_work" references an unsafe string in dereferencing the name of the workqueue. As the name is allocated, it could later be freed, and the pointer to that string could stay on the tracing buffer. If the trace buffer is read after the string is freed, it will reference an unsafe pointer. I added a new verifier to make sure that all strings referenced in the output of the trace buffer is safe to read and this triggered on the workqueue_queue_work trace event: workqueue_queue_work: work struct=00000000b2b235c7 function=gc_worker workqueue=(0xffff888100051160:events_power_efficient)[UNSAFE-MEMORY] req_cpu=256 cpu=1 workqueue_queue_work: work struct=00000000c344caec function=flush_to_ldisc workqueue=(0xffff888100054d60:events_unbound)[UNSAFE-MEMORY] req_cpu=256 cpu=4294967295 workqueue_queue_work: work struct=00000000b2b235c7 function=gc_worker workqueue=(0xffff888100051160:events_power_efficient)[UNSAFE-MEMORY] req_cpu=256 cpu=1 workqueue_queue_work: work struct=000000000b238b3f function=vmstat_update workqueue=(0xffff8881000c3760:mm_percpu_wq)[UNSAFE-MEMORY] req_cpu=1 cpu=1 Also, if this event is read via a user space application like perf or trace-cmd, the name would only be an address and useless information: workqueue_queue_work: work struct=0xffff953f80b4b918 function=disk_events_workfn workqueue=ffff953f8005d378 req_cpu=8192 cpu=5 Cc: Zqiang <[email protected]> Cc: Tejun Heo <[email protected]> Fixes: 7bf9c4a88e3e3 ("workqueue: tracing the name of the workqueue instead of it's address") Signed-off-by: Steven Rostedt (VMware) <[email protected]>
2021-03-18firmware: stratix10-svc: reset COMMAND_RECONFIG_FLAG_PARTIAL to 0Richard Gong1-1/+1
Clean up COMMAND_RECONFIG_FLAG_PARTIAL flag by resetting it to 0, which aligns with the firmware settings. Fixes: 36847f9e3e56 ("firmware: stratix10-svc: correct reconfig flag and timeout values") Signed-off-by: Richard Gong <[email protected]> Reviewed-by: Tom Rix <[email protected]> Signed-off-by: Moritz Fischer <[email protected]>
2021-03-18selftest/bpf: Add a test to check trampoline freeing logic.Alexei Starovoitov2-0/+113
Add a selftest for commit e21aa341785c ("bpf: Fix fexit trampoline.") to make sure that attaching fexit prog to a sleeping kernel function will trigger appropriate trampoline and program destruction. Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected]
2021-03-18Revert "PM: ACPI: reboot: Use S5 for reboot"Josef Bacik1-2/+0
This reverts commit d60cd06331a3566d3305b3c7b566e79edf4e2095. This patch causes a panic when rebooting my Dell Poweredge r440. I do not have the full panic log as it's lost at that stage of the reboot and I do not have a serial console. Reverting this patch makes my system able to reboot again. Signed-off-by: Josef Bacik <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2021-03-18btrfs: fix sleep while in non-sleep context during qgroup removalFilipe Manana1-2/+10
While removing a qgroup's sysfs entry we end up taking the kernfs_mutex, through kobject_del(), while holding the fs_info->qgroup_lock spinlock, producing the following trace: [821.843637] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281 [821.843641] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 28214, name: podman [821.843644] CPU: 3 PID: 28214 Comm: podman Tainted: G W 5.11.6 #15 [821.843646] Hardware name: Dell Inc. PowerEdge R330/084XW4, BIOS 2.11.0 12/08/2020 [821.843647] Call Trace: [821.843650] dump_stack+0xa1/0xfb [821.843656] ___might_sleep+0x144/0x160 [821.843659] mutex_lock+0x17/0x40 [821.843662] kernfs_remove_by_name_ns+0x1f/0x80 [821.843666] sysfs_remove_group+0x7d/0xe0 [821.843668] sysfs_remove_groups+0x28/0x40 [821.843670] kobject_del+0x2a/0x80 [821.843672] btrfs_sysfs_del_one_qgroup+0x2b/0x40 [btrfs] [821.843685] __del_qgroup_rb+0x12/0x150 [btrfs] [821.843696] btrfs_remove_qgroup+0x288/0x2a0 [btrfs] [821.843707] btrfs_ioctl+0x3129/0x36a0 [btrfs] [821.843717] ? __mod_lruvec_page_state+0x5e/0xb0 [821.843719] ? page_add_new_anon_rmap+0xbc/0x150 [821.843723] ? kfree+0x1b4/0x300 [821.843725] ? mntput_no_expire+0x55/0x330 [821.843728] __x64_sys_ioctl+0x5a/0xa0 [821.843731] do_syscall_64+0x33/0x70 [821.843733] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [821.843736] RIP: 0033:0x4cd3fb [821.843741] RSP: 002b:000000c000906b20 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [821.843744] RAX: ffffffffffffffda RBX: 000000c000050000 RCX: 00000000004cd3fb [821.843745] RDX: 000000c000906b98 RSI: 000000004010942a RDI: 000000000000000f [821.843747] RBP: 000000c000907cd0 R08: 000000c000622901 R09: 0000000000000000 [821.843748] R10: 000000c000d992c0 R11: 0000000000000206 R12: 000000000000012d [821.843749] R13: 000000000000012c R14: 0000000000000200 R15: 0000000000000049 Fix this by removing the qgroup sysfs entry while not holding the spinlock, since the spinlock is only meant for protection of the qgroup rbtree. Reported-by: Stuart Shelton <[email protected]> Link: https://lore.kernel.org/linux-btrfs/[email protected]/ Fixes: 49e5fb46211de0 ("btrfs: qgroup: export qgroups in sysfs") CC: [email protected] # 5.10+ Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Filipe Manana <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
2021-03-18io_uring: don't leak creds on SQO attach errorPavel Begunkov1-11/+6
Attaching to already dead/dying SQPOLL task is disallowed in io_sq_offload_create(), but cleanup is hand coded by calling io_put_sq_data()/etc., that miss to put ctx->sq_creds. Defer everything to error-path io_sq_thread_finish(), adding ctx->sqd_list in the error case as well as finish will handle it. Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-03-18io_uring: use typesafe pointers in io_uring_taskStefan Metzmacher1-2/+2
Signed-off-by: Stefan Metzmacher <[email protected]> Link: https://lore.kernel.org/r/ce2a598e66e48347bb04afbaf2acc67c0cc7971a.1615809009.git.metze@samba.org Signed-off-by: Jens Axboe <[email protected]>
2021-03-18io_uring: remove structures from include/linux/io_uring.hStefan Metzmacher3-26/+25
Link: https://lore.kernel.org/r/8c1d14f3748105f4caeda01716d47af2fa41d11c.1615809009.git.metze@samba.org Signed-off-by: Stefan Metzmacher <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2021-03-18io_uring: imply MSG_NOSIGNAL for send[msg]()/recv[msg]() callsStefan Metzmacher1-4/+4
We never want to generate any SIGPIPE, -EPIPE only is much better. Signed-off-by: Stefan Metzmacher <[email protected]> Link: https://lore.kernel.org/r/38961085c3ec49fd21550c7788f214d1ff02d2d4.1615908477.git.metze@samba.org Signed-off-by: Jens Axboe <[email protected]>
2021-03-18selftests: kvm: Add basic Hyper-V clocksources testsVitaly Kuznetsov3-0/+262
Introduce a new selftest for Hyper-V clocksources (MSR-based reference TSC and TSC page). As a starting point, test the following: 1) Reference TSC is 1Ghz clock. 2) Reference TSC and TSC page give the same reading. 3) TSC page gets updated upon KVM_SET_CLOCK call. 4) TSC page does not get updated when guest opted for reenlightenment. 5) Disabled TSC page doesn't get updated. Signed-off-by: Vitaly Kuznetsov <[email protected]> Message-Id: <[email protected]> [Add a host-side test using TSC + KVM_GET_MSR too. - Paolo] Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-18ALSA: usb-audio: Fix unintentional sign extension issueColin Ian King1-2/+2
The shifting of the u8 integer device by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a 64 bit unsigned long. In the event that the top bit of device is set then all then all the upper 32 bits of the unsigned long will end up as also being set because of the sign-extension. Fix this by casting device to an unsigned long before the shift. Addresses-Coverity: ("Unintended sign extension") Fixes: a07df82c7990 ("ALSA: usb-audio: Add DJM750 to Pioneer mixer quirk") Signed-off-by: Colin Ian King <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]>
2021-03-18Merge tag 'asoc-fix-v5.12-rc2' of ↵Takashi Iwai31-286/+232
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v5.12 Quite a lot of mostly platform specific fixes here, the only one which is generic is a fix for regressions on devices with more complex clocking support with simple-card. There's also a few new device IDs and platform quirks.
2021-03-18platform/x86: thinkpad_acpi: check dytc version for lapmode sysfsMark Pearson1-26/+65
Lenovo platforms with DYTC versions earlier than version 5 don't set the lapmode interface correctly, causing issues with thermald on older platforms. Add checking to only create the dytc_lapmode interface for version 5 and later. Fixes: 1ac09656bded ("platform/x86: thinkpad_acpi: Add palm sensor support") Signed-off-by: Mark Pearson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Hans de Goede <[email protected]>
2021-03-18KVM: x86: hyper-v: Don't touch TSC page values when guest opted for ↵Vitaly Kuznetsov1-1/+25
re-enlightenment When guest opts for re-enlightenment notifications upon migration, it is in its right to assume that TSC page values never change (as they're only supposed to change upon migration and the host has to keep things as they are before it receives confirmation from the guest). This is mostly true until the guest is migrated somewhere. KVM userspace (e.g. QEMU) will trigger masterclock update by writing to HV_X64_MSR_REFERENCE_TSC, by calling KVM_SET_CLOCK,... and as TSC value and kvmclock reading drift apart (even slightly), the update causes TSC page values to change. The issue at hand is that when Hyper-V is migrated, it uses stale (cached) TSC page values to compute the difference between its own clocksource (provided by KVM) and its guests' TSC pages to program synthetic timers and in some cases, when TSC page is updated, this puts all stimer expirations in the past. This, in its turn, causes an interrupt storm and L2 guests not making much forward progress. Note, KVM doesn't fully implement re-enlightenment notification. Basically, the support for reenlightenment MSRs is just a stub and userspace is only expected to expose the feature when TSC scaling on the expected destination hosts is available. With TSC scaling, no real re-enlightenment is needed as TSC frequency doesn't change. With TSC scaling becoming ubiquitous, it likely makes little sense to fully implement re-enlightenment in KVM. Prevent TSC page from being updated after migration. In case it's not the guest who's initiating the change and when TSC page is already enabled, just keep it as it is: TSC value is supposed to be preserved across migration and TSC frequency can't change with re-enlightenment enabled. The guest is doomed anyway if any of this is not true. Signed-off-by: Vitaly Kuznetsov <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-18KVM: x86: hyper-v: Track Hyper-V TSC page statusVitaly Kuznetsov2-14/+52
Create an infrastructure for tracking Hyper-V TSC page status, i.e. if it was updated from guest/host side or if we've failed to set it up (because e.g. guest wrote some garbage to HV_X64_MSR_REFERENCE_TSC) and there's no need to retry. Also, in a hypothetical situation when we are in 'always catchup' mode for TSC we can now avoid contending 'hv->hv_lock' on every guest enter by setting the state to HV_TSC_PAGE_BROKEN after compute_tsc_page_parameters() returns false. Check for HV_TSC_PAGE_SET state instead of '!hv->tsc_ref.tsc_sequence' in get_time_ref_counter() to properly handle the situation when we failed to write the updated TSC page values to the guest. Signed-off-by: Vitaly Kuznetsov <[email protected]> Message-Id: <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2021-03-18i2c: bail out early when RDWR parameters are wrongWolfram Sang1-2/+7
The buggy parameters currently get caught later, but emit a noisy WARN. Userspace should not be able to trigger this, so add similar checks much earlier. Also avoids some unneeded code paths, of course. Apply kernel coding stlye to a comment while here. Reported-by: [email protected] Tested-by: [email protected] Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-03-18i2c: i2c-scmi: Drop unused ACPI_MODULE_NAME definitionRafael J. Wysocki1-2/+0
The ACPI_MODULE_NAME() definition is only used by the message printing macros from ACPICA that are not used by the code in question, so it is redundant. Drop it. No functional impact. Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-03-18i2c: powermac: remove uncertainty about SMBUS_BLOCK transfersWolfram Sang1-5/+0
The driver does the correct thing, so no need to question it. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-03-18i2c: rcar: implement atomic transfersUlrich Hecht1-6/+78
Implements atomic transfers. Tested by rebooting an r8a7790 Lager board after connecting the i2c-rcar controller to the PMIC in arch/arm/boot/dts/r8a7790-lager.dts like so: compatible = "i2c-demux-pinctrl"; pinctrl-names = "default"; pinctrl-0 = <&pmic_irq_pins>; - i2c-parent = <&iic3>, <&i2c3>; + i2c-parent = <&i2c3>, <&iic3>; i2c-bus-name = "i2c-pwr"; #address-cells = <1>; #size-cells = <0>; Signed-off-by: Ulrich Hecht <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-03-18i2c: stm32f7: indicate the address being accessed on errorsAlain Volmat1-3/+6
To help debugging issues, add the address of the slave being accessed when getting an error. Signed-off-by: Alain Volmat <[email protected]> Signed-off-by: Pierre-Yves MORDRET <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-03-18i2c: stm32f7: add support for DNF i2c-digital-filter bindingAlain Volmat1-11/+16
Add the support for the i2c-digital-filter binding, allowing to enable the digital filter via the device-tree and indicate its value in the DT. Signed-off-by: Alain Volmat <[email protected]> Reviewed-by: Pierre-Yves MORDRET <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-03-18i2c: stm32f7: support DT binding i2c-analog-filterAlain Volmat1-10/+10
Replace driver internally coded enabling/disabling of the analog-filter with the DT binding "i2c-analog-filter". Signed-off-by: Alain Volmat <[email protected]> Reviewed-by: Pierre-Yves MORDRET <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2021-03-18iommu/tegra-smmu: Make tegra_smmu_probe_device() to handle all IOMMU phandlesDmitry Osipenko1-4/+3
The tegra_smmu_probe_device() handles only the first IOMMU device-tree phandle, skipping the rest. Devices like 3D module on Tegra30 have multiple IOMMU phandles, one for each h/w block, and thus, only one IOMMU phandle is added to fwspec for the 3D module, breaking GPU. Previously this problem was masked by tegra_smmu_attach_dev() which didn't use the fwspec, but parsed the DT by itself. The previous commit to tegra-smmu driver partially reverted changes that caused problems for T124 and now we have tegra_smmu_attach_dev() that uses the fwspec and the old-buggy variant of tegra_smmu_probe_device() which skips secondary IOMMUs. Make tegra_smmu_probe_device() not to skip the secondary IOMMUs. This fixes a partially attached IOMMU of the 3D module on Tegra30 and now GPU works properly once again. Fixes: 765a9d1d02b2 ("iommu/tegra-smmu: Fix mc errors on tegra124-nyan") Signed-off-by: Dmitry Osipenko <[email protected]> Tested-by: Nicolin Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]>
2021-03-18iommu/amd: Keep track of amd_iommu_irq_remap stateJoerg Roedel1-1/+4
The amd_iommu_irq_remap variable is set to true in amd_iommu_prepare(). But if initialization fails it is not set to false. Fix that and correctly keep track of whether irq remapping is enabled or not. References: https://bugzilla.kernel.org/show_bug.cgi?id=212133 References: https://bugzilla.suse.com/show_bug.cgi?id=1183132 Fixes: b34f10c2dc59 ("iommu/amd: Stop irq_remapping_select() matching when remapping is disabled") Cc: [email protected] # v5.11 Signed-off-by: Joerg Roedel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Huang Rui <[email protected]>
2021-03-18iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabledJoerg Roedel1-4/+4
Don't even try to initialize the AMD IOMMU hardware when amd_iommu=off has been passed on the kernel command line. References: https://bugzilla.kernel.org/show_bug.cgi?id=212133 References: https://bugzilla.suse.com/show_bug.cgi?id=1183132 Cc: [email protected] # v5.11 Signed-off-by: Joerg Roedel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Huang Rui <[email protected]>
2021-03-18iommu/amd: Move Stoney Ridge check to detect_ivrs()Joerg Roedel1-11/+12
The AMD IOMMU will not be enabled on AMD Stoney Ridge systems. Bail out even earlier and refuse to even detect the IOMMU there. References: https://bugzilla.kernel.org/show_bug.cgi?id=212133 References: https://bugzilla.suse.com/show_bug.cgi?id=1183132 Cc: [email protected] # v5.11 Signed-off-by: Joerg Roedel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Huang Rui <[email protected]>
2021-03-18staging: vt665x: fix alignment constraintsEdmundo Carmona Antoranz1-2/+2
Removing 2 instances of alignment warnings drivers/staging/vt6655/rxtx.h:153:1: warning: alignment 1 of ‘struct vnt_cts’ is less than 2 [-Wpacked-not-aligned] drivers/staging/vt6655/rxtx.h:163:1: warning: alignment 1 of ‘struct vnt_cts_fb’ is less than 2 [-Wpacked-not-aligned] The root cause seems to be that _because_ struct ieee80211_cts is marked as __aligned(2), this requires any encapsulating struct to also have an alignment of 2. Fixes: 2faf12c57efe ("staging: vt665x: fix alignment constraints") Reviewed-by: Arnd Bergmann <[email protected]> Signed-off-by: Edmundo Carmona Antoranz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.