]> Git Repo - linux.git/log
linux.git
9 months agoMerge branch 'efi/next' into efi/urgent
Ard Biesheuvel [Tue, 4 Jun 2024 17:31:03 +0000 (19:31 +0200)]
Merge branch 'efi/next' into efi/urgent

9 months agoPCI: Revert the cfg_access_lock lockdep mechanism
Dan Williams [Fri, 31 May 2024 01:04:24 +0000 (18:04 -0700)]
PCI: Revert the cfg_access_lock lockdep mechanism

While the experiment did reveal that there are additional places that are
missing the lock during secondary bus reset, one of the places that needs
to take cfg_access_lock (pci_bus_lock()) is not prepared for lockdep
annotation.

Specifically, pci_bus_lock() takes pci_dev_lock() recursively and is
currently dependent on the fact that the device_lock() is marked
lockdep_set_novalidate_class(&dev->mutex). Otherwise, without that
annotation, pci_bus_lock() would need to use something like a new
pci_dev_lock_nested() helper, a scheme to track a PCI device's depth in the
topology, and a hope that the depth of a PCI tree never exceeds the max
value for a lockdep subclass.

The alternative to ripping out the lockdep coverage would be to deploy a
dynamic lock key for every PCI device. Unfortunately, there is evidence
that increasing the number of keys that lockdep needs to track to be
per-PCI-device is prohibitively expensive for something like the
cfg_access_lock.

The main motivation for adding the annotation in the first place was to
catch unlocked secondary bus resets, not necessarily catch lock ordering
problems between cfg_access_lock and other locks. Solve that narrower
problem with follow-on patches, and just due to targeted revert for now.

Link: https://lore.kernel.org/r/171711746402.1628941.14575335981264103013.stgit@dwillia2-xfh.jf.intel.com
Fixes: 7e89efc6e9e4 ("PCI: Lock upstream bridge for pci_reset_function()")
Reported-by: Imre Deak <[email protected]>
Closes: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_134186v1/shard-dg2-1/igt@[email protected]
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>
Tested-by: Hans de Goede <[email protected]>
Tested-by: Kalle Valo <[email protected]>
Reviewed-by: Dave Jiang <[email protected]>
Cc: Jani Saarinen <[email protected]>
9 months agodrm/xe/pf: Update the LMTT when freeing VF GT config
Michal Wajdeczko [Mon, 27 May 2024 11:54:08 +0000 (13:54 +0200)]
drm/xe/pf: Update the LMTT when freeing VF GT config

The LMTT must be updated whenever we change the VF LMEM configuration.
We missed that step when freeing the whole VF GT config, which could
result in stale PTE in LMTT or LMTT PT object leaks. Fix that.

Fixes: ac6598aed1b3 ("drm/xe/pf: Add support to configure SR-IOV VFs")
Signed-off-by: Michal Wajdeczko <[email protected]>
Reviewed-by: Piotr Piórkowski <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit c063cce7df3a765539e2a2d75ab943f334446cce)
Signed-off-by: Thomas Hellström <[email protected]>
9 months agoHID: logitech-hidpp: add missing MODULE_DESCRIPTION() macro
Jeff Johnson [Tue, 4 Jun 2024 06:00:59 +0000 (23:00 -0700)]
HID: logitech-hidpp: add missing MODULE_DESCRIPTION() macro

make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/hid/hid-logitech-hidpp.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
9 months agoHID: intel-ish-hid: fix endian-conversion
Arnd Bergmann [Mon, 3 Jun 2024 07:41:03 +0000 (09:41 +0200)]
HID: intel-ish-hid: fix endian-conversion

The newly added file causes a ton of sparse warnings about the
incorrect use of __le32 and similar types:

drivers/hid/intel-ish-hid/ishtp/loader.h:41:23: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.h:42:27: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.h:43:24: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.h:44:24: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.h:45:22: error: invalid bitfield specifier for type restricted __le32.
drivers/hid/intel-ish-hid/ishtp/loader.c:172:33: warning: restricted __le32 degrades to integer
drivers/hid/intel-ish-hid/ishtp/loader.c:178:50: warning: incorrect type in assignment (different base types)
drivers/hid/intel-ish-hid/ishtp/loader.c:178:50:    expected restricted __le32 [usertype] length
drivers/hid/intel-ish-hid/ishtp/loader.c:178:50:    got unsigned long
drivers/hid/intel-ish-hid/ishtp/loader.c:179:50: warning: incorrect type in assignment (different base types)
drivers/hid/intel-ish-hid/ishtp/loader.c:179:50:    expected restricted __le32 [usertype] fw_off
drivers/hid/intel-ish-hid/ishtp/loader.c:179:50:    got unsigned int [usertype] offset
drivers/hid/intel-ish-hid/ishtp/loader.c:180:17: warning: cast from restricted __le32
drivers/hid/intel-ish-hid/ishtp/loader.c:183:24: warning: invalid assignment: +=
drivers/hid/intel-ish-hid/ishtp/loader.c:183:24:    left side has type unsigned int
drivers/hid/intel-ish-hid/ishtp/loader.c:183:24:    right side has type restricted __le32

Add the necessary conversions and use temporary variables where appropriate
to avoid converting back.

Fixes: 579a267e4617 ("HID: intel-ish-hid: Implement loading firmware from host feature")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Zhang Lixu <[email protected]>
Tested-by: Zhang Lixu <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
9 months agoHID: nintendo: Fix an error handling path in nintendo_hid_probe()
Christophe JAILLET [Sun, 26 May 2024 15:05:59 +0000 (17:05 +0200)]
HID: nintendo: Fix an error handling path in nintendo_hid_probe()

joycon_leds_create() has a ida_alloc() call. So if an error occurs after
it, a corresponding ida_free() call is needed, as already done in the
.remove function.

This is not 100% perfect, because if ida_alloc() fails, then
'ctlr->player_id' will forced to be U32_MAX, and an error will be logged
when ida_free() is called.

Considering that this can't happen in real life, no special handling is
done to handle it.

Fixes: 5307de63d71d ("HID: nintendo: use ida for LED player id")
Signed-off-by: Christophe JAILLET <[email protected]>
Reviewed-by: Silvan Jegen <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
9 months agoHID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()
José Expósito [Fri, 24 May 2024 13:05:39 +0000 (15:05 +0200)]
HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()

Fix a memory leak on logi_dj_recv_send_report() error path.

Fixes: 6f20d3261265 ("HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode()")
Signed-off-by: José Expósito <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
9 months agoKVM: arm64: Ensure that SME controls are disabled in protected mode
Fuad Tabba [Mon, 3 Jun 2024 12:28:51 +0000 (13:28 +0100)]
KVM: arm64: Ensure that SME controls are disabled in protected mode

KVM (and pKVM) do not support SME guests. Therefore KVM ensures
that the host's SME state is flushed and that SME controls for
enabling access to ZA storage and for streaming are disabled.

pKVM needs to protect against a buggy/malicious host. Ensure that
it wouldn't run a guest when protected mode is enabled should any
of the SME controls be enabled.

Signed-off-by: Fuad Tabba <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Zyngier <[email protected]>
9 months agoKVM: arm64: Refactor CPACR trap bit setting/clearing to use ELx format
Fuad Tabba [Mon, 3 Jun 2024 12:28:50 +0000 (13:28 +0100)]
KVM: arm64: Refactor CPACR trap bit setting/clearing to use ELx format

When setting/clearing CPACR bits for EL0 and EL1, use the ELx
format of the bits, which covers both. This makes the code
clearer, and reduces the chances of accidentally missing a bit.

No functional change intended.

Reviewed-by: Oliver Upton <[email protected]>
Signed-off-by: Fuad Tabba <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Zyngier <[email protected]>
9 months agoKVM: arm64: Consolidate initializing the host data's fpsimd_state/sve in pKVM
Fuad Tabba [Mon, 3 Jun 2024 12:28:49 +0000 (13:28 +0100)]
KVM: arm64: Consolidate initializing the host data's fpsimd_state/sve in pKVM

Now that we have introduced finalize_init_hyp_mode(), lets
consolidate the initializing of the host_data fpsimd_state and
sve state.

Reviewed-by: Oliver Upton <[email protected]>
Signed-off-by: Fuad Tabba <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Zyngier <[email protected]>
9 months agoKVM: arm64: Eagerly restore host fpsimd/sve state in pKVM
Fuad Tabba [Mon, 3 Jun 2024 12:28:48 +0000 (13:28 +0100)]
KVM: arm64: Eagerly restore host fpsimd/sve state in pKVM

When running in protected mode we don't want to leak protected
guest state to the host, including whether a guest has used
fpsimd/sve. Therefore, eagerly restore the host state on guest
exit when running in protected mode, which happens only if the
guest has used fpsimd/sve.

Reviewed-by: Oliver Upton <[email protected]>
Signed-off-by: Fuad Tabba <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Zyngier <[email protected]>
9 months agoKVM: arm64: Allocate memory mapped at hyp for host sve state in pKVM
Fuad Tabba [Mon, 3 Jun 2024 12:28:47 +0000 (13:28 +0100)]
KVM: arm64: Allocate memory mapped at hyp for host sve state in pKVM

Protected mode needs to maintain (save/restore) the host's sve
state, rather than relying on the host kernel to do that. This is
to avoid leaking information to the host about guests and the
type of operations they are performing.

As a first step towards that, allocate memory mapped at hyp, per
cpu, for the host sve state. The following patch will use this
memory to save/restore the host state.

Reviewed-by: Oliver Upton <[email protected]>
Signed-off-by: Fuad Tabba <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Zyngier <[email protected]>
9 months agoKVM: arm64: Specialize handling of host fpsimd state on trap
Fuad Tabba [Mon, 3 Jun 2024 12:28:46 +0000 (13:28 +0100)]
KVM: arm64: Specialize handling of host fpsimd state on trap

In subsequent patches, n/vhe will diverge on saving the host
fpsimd/sve state when taking a guest fpsimd/sve trap. Add a
specialized helper to handle it.

No functional change intended.

Reviewed-by: Mark Brown <[email protected]>
Reviewed-by: Oliver Upton <[email protected]>
Signed-off-by: Fuad Tabba <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Zyngier <[email protected]>
9 months agoKVM: arm64: Abstract set/clear of CPTR_EL2 bits behind helper
Fuad Tabba [Mon, 3 Jun 2024 12:28:45 +0000 (13:28 +0100)]
KVM: arm64: Abstract set/clear of CPTR_EL2 bits behind helper

The same traps controlled by CPTR_EL2 or CPACR_EL1 need to be
toggled in different parts of the code, but the exact bits and
their polarity differ between these two formats and the mode
(vhe/nvhe/hvhe).

To reduce the amount of duplicated code and the chance of getting
the wrong bit/polarity or missing a field, abstract the set/clear
of CPTR_EL2 bits behind a helper.

Since (h)VHE is the way of the future, use the CPACR_EL1 format,
which is a subset of the VHE CPTR_EL2, as a reference.

No functional change intended.

Suggested-by: Oliver Upton <[email protected]>
Reviewed-by: Oliver Upton <[email protected]>
Signed-off-by: Fuad Tabba <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Zyngier <[email protected]>
9 months agoKVM: arm64: Fix prototype for __sve_save_state/__sve_restore_state
Fuad Tabba [Mon, 3 Jun 2024 12:28:44 +0000 (13:28 +0100)]
KVM: arm64: Fix prototype for __sve_save_state/__sve_restore_state

Since the prototypes for __sve_save_state/__sve_restore_state at
hyp were added, the underlying macro has acquired a third
parameter for saving/restoring ffr.

Fix the prototypes to account for the third parameter, and
restore the ffr for the guest since it is saved.

Suggested-by: Mark Brown <[email protected]>
Signed-off-by: Fuad Tabba <[email protected]>
Reviewed-by: Mark Brown <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Zyngier <[email protected]>
9 months agoKVM: arm64: Reintroduce __sve_save_state
Fuad Tabba [Mon, 3 Jun 2024 12:28:43 +0000 (13:28 +0100)]
KVM: arm64: Reintroduce __sve_save_state

Now that the hypervisor is handling the host sve state in
protected mode, it needs to be able to save it.

This reverts commit e66425fc9ba3 ("KVM: arm64: Remove unused
__sve_save_state").

Reviewed-by: Oliver Upton <[email protected]>
Signed-off-by: Fuad Tabba <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Marc Zyngier <[email protected]>
9 months agoio_uring: fix possible deadlock in io_register_iowq_max_workers()
Hagar Hemdan [Tue, 4 Jun 2024 13:05:27 +0000 (13:05 +0000)]
io_uring: fix possible deadlock in io_register_iowq_max_workers()

The io_register_iowq_max_workers() function calls io_put_sq_data(),
which acquires the sqd->lock without releasing the uring_lock.
Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lock
before acquiring sqd->lock"), this can lead to a potential deadlock
situation.

To resolve this issue, the uring_lock is released before calling
io_put_sq_data(), and then it is re-acquired after the function call.

This change ensures that the locks are acquired in the correct
order, preventing the possibility of a deadlock.

Suggested-by: Maximilian Heyne <[email protected]>
Signed-off-by: Hagar Hemdan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>
9 months agoio_uring/io-wq: avoid garbage value of 'match' in io_wq_enqueue()
Su Hui [Tue, 4 Jun 2024 12:12:43 +0000 (20:12 +0800)]
io_uring/io-wq: avoid garbage value of 'match' in io_wq_enqueue()

Clang static checker (scan-build) warning:
o_uring/io-wq.c:line 1051, column 3
The expression is an uninitialized value. The computed value will
also be garbage.

'match.nr_pending' is used in io_acct_cancel_pending_work(), but it is
not fully initialized. Change the order of assignment for 'match' to fix
this problem.

Fixes: 42abc95f05bf ("io-wq: decouple work_list protection from the big wqe->lock")
Signed-off-by: Su Hui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>
9 months agoio_uring/napi: fix timeout calculation
Jens Axboe [Mon, 3 Jun 2024 19:56:53 +0000 (13:56 -0600)]
io_uring/napi: fix timeout calculation

Not quite sure what __io_napi_adjust_timeout() was attemping to do, it's
adjusting both the NAPI timeout and the general overall timeout, and
calculating a value that is never used. The overall timeout is a super
set of the NAPI timeout, and doesn't need adjusting. The only thing we
really need to care about is that the NAPI timeout doesn't exceed the
overall timeout. If a user asked for a timeout of eg 5 usec and NAPI
timeout is 10 usec, then we should not spin for 10 usec.

While in there, sanitize the time checking a bit. If we have a negative
value in the passed in timeout, discard it. Round up the value as well,
so we don't end up with a NAPI timeout for the majority of the wait,
with only a tiny sleep value at the end.

Hence the only case we need to care about is if the NAPI timeout is
larger than the overall timeout. If it is, cap the NAPI timeout at what
the overall timeout is.

Cc: [email protected]
Fixes: 8d0c12a80cde ("io-uring: add napi busy poll support")
Reported-by: Lewis Baker <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
9 months agoiommu/amd: Fix Invalid wait context issue
Vasant Hegde [Thu, 30 May 2024 08:48:01 +0000 (08:48 +0000)]
iommu/amd: Fix Invalid wait context issue

With commit c4cb23111103 ("iommu/amd: Add support for enable/disable IOPF")
we are hitting below issue. This happens because in IOPF enablement path
it holds spin lock with irq disable and then tries to take mutex lock.

dmesg:
-----
[    0.938739] =============================
[    0.938740] [ BUG: Invalid wait context ]
[    0.938742] 6.10.0-rc1+ #1 Not tainted
[    0.938745] -----------------------------
[    0.938746] swapper/0/1 is trying to lock:
[    0.938748] ffffffff8c9f01d8 (&port_lock_key){....}-{3:3}, at: serial8250_console_write+0x78/0x4a0
[    0.938767] other info that might help us debug this:
[    0.938768] context-{5:5}
[    0.938769] 7 locks held by swapper/0/1:
[    0.938772]  #0: ffff888101a91310 (&group->mutex){+.+.}-{4:4}, at: bus_iommu_probe+0x70/0x160
[    0.938790]  #1: ffff888101d1f1b8 (&domain->lock){....}-{3:3}, at: amd_iommu_attach_device+0xa5/0x700
[    0.938799]  #2: ffff888101cc3d18 (&dev_data->lock){....}-{3:3}, at: amd_iommu_attach_device+0xc5/0x700
[    0.938806]  #3: ffff888100052830 (&iommu->lock){....}-{2:2}, at: amd_iommu_iopf_add_device+0x3f/0xa0
[    0.938813]  #4: ffffffff8945a340 (console_lock){+.+.}-{0:0}, at: _printk+0x48/0x50
[    0.938822]  #5: ffffffff8945a390 (console_srcu){....}-{0:0}, at: console_flush_all+0x58/0x4e0
[    0.938867]  #6: ffffffff82459f80 (console_owner){....}-{0:0}, at: console_flush_all+0x1f0/0x4e0
[    0.938872] stack backtrace:
[    0.938874] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc1+ #1
[    0.938877] Hardware name: HP HP EliteBook 745 G3/807E, BIOS N73 Ver. 01.39 04/16/2019

Fix above issue by re-arranging code in attach device path:
  - move device PASID/IOPF enablement outside lock in AMD IOMMU driver.
    This is safe as core layer holds group->mutex lock before calling
    iommu_ops->attach_dev.

Reported-by: Borislav Petkov <[email protected]>
Reported-by: Mikhail Gavrilov <[email protected]>
Reported-by: Chris Bainbridge <[email protected]>
Fixes: c4cb23111103 ("iommu/amd: Add support for enable/disable IOPF")
Tested-by: Borislav Petkov <[email protected]>
Tested-by: Chris Bainbridge <[email protected]>
Tested-by: Mikhail Gavrilov <[email protected]>
Signed-off-by: Vasant Hegde <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
9 months agoiommu/amd: Check EFR[EPHSup] bit before enabling PPR
Vasant Hegde [Thu, 30 May 2024 07:11:18 +0000 (07:11 +0000)]
iommu/amd: Check EFR[EPHSup] bit before enabling PPR

Check for EFR[EPHSup] bit before enabling PPR. This bit must be set
to enable PPR.

Reported-by: Borislav Petkov <[email protected]>
Fixes: c4cb23111103 ("iommu/amd: Add support for enable/disable IOPF")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218900
Tested-by: Borislav Petkov <[email protected]>
Tested-by: Jean-Christophe Guillain <[email protected]>
Signed-off-by: Vasant Hegde <[email protected]>
Reviewed-by: Suravee Suthikulpanit <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
9 months agoiommu/amd: Fix workqueue name
Vasant Hegde [Wed, 29 May 2024 11:39:00 +0000 (11:39 +0000)]
iommu/amd: Fix workqueue name

Workqueue name length is crossing WQ_NAME_LEN limit. Fix it by changing
name format. New format : "iopf_queue/amdvi-<iommu-devid>"

kernel warning:
  [   11.146912] workqueue: name exceeds WQ_NAME_LEN. Truncating to: iopf_queue/amdiommu-0xc002-iopf

Reported-by: Borislav Petkov <[email protected]>
Fixes: 61928bab9d26 ("iommu/amd: Define per-IOMMU iopf_queue")
Signed-off-by: Vasant Hegde <[email protected]>
Acked-by: Borislav Petkov (AMD) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
9 months agoiommu: Return right value in iommu_sva_bind_device()
Lu Baolu [Tue, 28 May 2024 04:25:28 +0000 (12:25 +0800)]
iommu: Return right value in iommu_sva_bind_device()

iommu_sva_bind_device() should return either a sva bond handle or an
ERR_PTR value in error cases. Existing drivers (idxd and uacce) only
check the return value with IS_ERR(). This could potentially lead to
a kernel NULL pointer dereference issue if the function returns NULL
instead of an error pointer.

In reality, this doesn't cause any problems because iommu_sva_bind_device()
only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.
In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will
return an error, and the device drivers won't call iommu_sva_bind_device()
at all.

Fixes: 26b25a2b98e4 ("iommu: Bind process address spaces to devices")
Signed-off-by: Lu Baolu <[email protected]>
Reviewed-by: Jean-Philippe Brucker <[email protected]>
Reviewed-by: Kevin Tian <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Joerg Roedel <[email protected]>
9 months agoiommu/dma: Fix domain init
Robin Murphy [Mon, 20 May 2024 19:14:44 +0000 (20:14 +0100)]
iommu/dma: Fix domain init

Despite carefully rewording the kerneldoc to describe the new direct
interaction with dma_range_map, it seems I managed to confuse myself in
removing the redundant force_aperture check and ended up making the code
not do that at all. This led to dma_range_maps inadvertently being able
to set iovad->start_pfn = 0, and all the nonsensical chaos which ensues
from there. Restore the correct behaviour of constraining base_pfn to
the domain aperture regardless of dma_range_map, and not trying to apply
dma_range_map constraints to the basic IOVA domain since they will be
properly handled with reserved regions later.

Reported-by: Jon Hunter <[email protected]>
Reported-by: Jerry Snitselaar <[email protected]>
Fixes: ad4750b07d34 ("iommu/dma: Make limit checks self-contained")
Signed-off-by: Robin Murphy <[email protected]>
Tested-by: Jerry Snitselaar <[email protected]>
Reviewed-by: Jerry Snitselaar <[email protected]>
Link: https://lore.kernel.org/r/721fa6baebb0924aa40db0b8fb86bcb4538434af.1716232484.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <[email protected]>
9 months agoiommu/amd: Fix sysfs leak in iommu init
Kun(llfl) [Thu, 9 May 2024 00:42:20 +0000 (08:42 +0800)]
iommu/amd: Fix sysfs leak in iommu init

During the iommu initialization, iommu_init_pci() adds sysfs nodes.
However, these nodes aren't remove in free_iommu_resources() subsequently.

Fixes: 39ab9555c241 ("iommu: Add sysfs bindings for struct iommu_device")
Signed-off-by: Kun(llfl) <[email protected]>
Reviewed-by: Suravee Suthikulpanit <[email protected]>
Link: https://lore.kernel.org/r/c8e0d11c6ab1ee48299c288009cf9c5dae07b42d.1715215003.git.llfl@linux.alibaba.com
Signed-off-by: Joerg Roedel <[email protected]>
9 months agonet: tls: fix marking packets as decrypted
Jakub Kicinski [Thu, 30 May 2024 23:26:07 +0000 (16:26 -0700)]
net: tls: fix marking packets as decrypted

For TLS offload we mark packets with skb->decrypted to make sure
they don't escape the host without getting encrypted first.
The crypto state lives in the socket, so it may get detached
by a call to skb_orphan(). As a safety check - the egress path
drops all packets with skb->decrypted and no "crypto-safe" socket.

The skb marking was added to sendpage only (and not sendmsg),
because tls_device injected data into the TCP stack using sendpage.
This special case was missed when sendpage got folded into sendmsg.

Fixes: c5c37af6ecad ("tcp: Convert do_tcp_sendpages() to use MSG_SPLICE_PAGES")
Signed-off-by: Jakub Kicinski <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
9 months agoEDAC/igen6: Convert PCIBIOS_* return codes to errnos
Ilpo Järvinen [Mon, 27 May 2024 13:22:35 +0000 (16:22 +0300)]
EDAC/igen6: Convert PCIBIOS_* return codes to errnos

errcmd_enable_error_reporting() uses pci_{read,write}_config_word()
that return PCIBIOS_* codes. The return code is then returned all the
way into the probe function igen6_probe() that returns it as is. The
probe functions, however, should return normal errnos.

Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal
errno before returning it from errcmd_enable_error_reporting().

Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC")
Signed-off-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Qiuxu Zhuo <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
9 months agoEDAC/amd64: Convert PCIBIOS_* return codes to errnos
Ilpo Järvinen [Mon, 27 May 2024 13:22:34 +0000 (16:22 +0300)]
EDAC/amd64: Convert PCIBIOS_* return codes to errnos

gpu_get_node_map() uses pci_read_config_dword() that returns PCIBIOS_*
codes. The return code is then returned all the way into the module
init function amd64_edac_init() that returns it as is. The module init
functions, however, should return normal errnos.

Convert PCIBIOS_* returns code using pcibios_err_to_errno() into normal
errno before returning it from gpu_get_node_map().

For consistency, convert also the other similar cases which return
PCIBIOS_* codes even if they do not have any bugs at the moment.

Fixes: 4251566ebc1c ("EDAC/amd64: Cache and use GPU node map")
Signed-off-by: Ilpo Järvinen <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
9 months agoHID: core: remove unnecessary WARN_ON() in implement()
Nikita Zhandarovich [Fri, 17 May 2024 14:19:14 +0000 (07:19 -0700)]
HID: core: remove unnecessary WARN_ON() in implement()

Syzkaller hit a warning [1] in a call to implement() when trying
to write a value into a field of smaller size in an output report.

Since implement() already has a warn message printed out with the
help of hid_warn() and value in question gets trimmed with:
...
value &= m;
...
WARN_ON may be considered superfluous. Remove it to suppress future
syzkaller triggers.

[1]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
Modules linked in:
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
...
Call Trace:
 <TASK>
 __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
 usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:904 [inline]
 __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
...

Fixes: 95d1c8951e5b ("HID: simplify implement() a bit")
Reported-by: <[email protected]>
Suggested-by: Alan Stern <[email protected]>
Signed-off-by: Nikita Zhandarovich <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
9 months agoMerge tag 'wireless-2024-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git...
Jakub Kicinski [Tue, 4 Jun 2024 01:52:24 +0000 (18:52 -0700)]
Merge tag 'wireless-2024-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless

Kalle Valo says:

====================
wireless fixes for v6.10-rc3

The first fixes for v6.10. And we have a big one, I suspect the
biggest wireless pull request we ever had. There are fixes all over,
both in stack and drivers. Likely the most important here are mt76 not
working on mt7615 devices, ath11k not being able to connect to 6 GHz
networks and rtlwifi suffering from packet loss. But of course there's
much more.

* tag 'wireless-2024-06-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (37 commits)
  wifi: rtlwifi: Ignore IEEE80211_CONF_CHANGE_RETRY_LIMITS
  wifi: mt76: mt7615: add missing chanctx ops
  wifi: wilc1000: document SRCU usage instead of SRCU
  Revert "wifi: wilc1000: set atomic flag on kmemdup in srcu critical section"
  Revert "wifi: wilc1000: convert list management to RCU"
  wifi: mac80211: fix UBSAN noise in ieee80211_prep_hw_scan()
  wifi: mac80211: correctly parse Spatial Reuse Parameter Set element
  wifi: mac80211: fix Spatial Reuse element size check
  wifi: iwlwifi: mvm: don't read past the mfuart notifcation
  wifi: iwlwifi: mvm: Fix scan abort handling with HW rfkill
  wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
  wifi: iwlwifi: mvm: properly set 6 GHz channel direct probe option
  wifi: iwlwifi: mvm: handle BA session teardown in RF-kill
  wifi: iwlwifi: mvm: Handle BIGTK cipher in kek_kck cmd
  wifi: iwlwifi: mvm: remove stale STA link data during restart
  wifi: iwlwifi: dbg_ini: move iwl_dbg_tlv_free outside of debugfs ifdef
  wifi: iwlwifi: mvm: set properly mac header
  wifi: iwlwifi: mvm: revert gen2 TX A-MPDU size to 64
  wifi: iwlwifi: mvm: d3: fix WoWLAN command version lookup
  wifi: iwlwifi: mvm: fix a crash on 7265
  ...
====================

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agolib/test_rhashtable: add missing MODULE_DESCRIPTION() macro
Jeff Johnson [Sat, 1 Jun 2024 01:35:43 +0000 (18:35 -0700)]
lib/test_rhashtable: add missing MODULE_DESCRIPTION() macro

make allmodconfig && make W=1 C=1 reports:
WARNING: modpost: missing MODULE_DESCRIPTION() in lib/test_rhashtable.o

Add the missing invocation of the MODULE_DESCRIPTION() macro.

Signed-off-by: Jeff Johnson <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoMerge branch 'dst_cache-fix-possible-races'
Jakub Kicinski [Tue, 4 Jun 2024 01:50:13 +0000 (18:50 -0700)]
Merge branch 'dst_cache-fix-possible-races'

Eric Dumazet says:

====================
dst_cache: fix possible races

This series is inspired by various undisclosed syzbot
reports hinting at corruptions in dst_cache structures.

It seems at least four users of dst_cache are racy against
BH reentrancy.

Last patch is adding a DEBUG_NET check to catch future misuses.
====================

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agonet: dst_cache: add two DEBUG_NET warnings
Eric Dumazet [Fri, 31 May 2024 13:26:36 +0000 (13:26 +0000)]
net: dst_cache: add two DEBUG_NET warnings

After fixing four different bugs involving dst_cache
users, it might be worth adding a check about BH being
blocked by dst_cache callers.

DEBUG_NET_WARN_ON_ONCE(!in_softirq());

It is not fatal, if we missed valid case where no
BH deadlock is to be feared, we might change this.

Signed-off-by: Eric Dumazet <[email protected]>
Acked-by: Paolo Abeni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoila: block BH in ila_output()
Eric Dumazet [Fri, 31 May 2024 13:26:35 +0000 (13:26 +0000)]
ila: block BH in ila_output()

As explained in commit 1378817486d6 ("tipc: block BH
before using dst_cache"), net/core/dst_cache.c
helpers need to be called with BH disabled.

ila_output() is called from lwtunnel_output()
possibly from process context, and under rcu_read_lock().

We might be interrupted by a softirq, re-enter ila_output()
and corrupt dst_cache data structures.

Fix the race by using local_bh_disable().

Signed-off-by: Eric Dumazet <[email protected]>
Acked-by: Paolo Abeni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoipv6: sr: block BH in seg6_output_core() and seg6_input_core()
Eric Dumazet [Fri, 31 May 2024 13:26:34 +0000 (13:26 +0000)]
ipv6: sr: block BH in seg6_output_core() and seg6_input_core()

As explained in commit 1378817486d6 ("tipc: block BH
before using dst_cache"), net/core/dst_cache.c
helpers need to be called with BH disabled.

Disabling preemption in seg6_output_core() is not good enough,
because seg6_output_core() is called from process context,
lwtunnel_output() only uses rcu_read_lock().

We might be interrupted by a softirq, re-enter seg6_output_core()
and corrupt dst_cache data structures.

Fix the race by using local_bh_disable() instead of
preempt_disable().

Apply a similar change in seg6_input_core().

Fixes: fa79581ea66c ("ipv6: sr: fix several BUGs when preemption is enabled")
Fixes: 6c8702c60b88 ("ipv6: sr: add support for SRH encapsulation and injection with lwtunnels")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: David Lebrun <[email protected]>
Acked-by: Paolo Abeni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agonet: ipv6: rpl_iptunnel: block BH in rpl_output() and rpl_input()
Eric Dumazet [Fri, 31 May 2024 13:26:33 +0000 (13:26 +0000)]
net: ipv6: rpl_iptunnel: block BH in rpl_output() and rpl_input()

As explained in commit 1378817486d6 ("tipc: block BH
before using dst_cache"), net/core/dst_cache.c
helpers need to be called with BH disabled.

Disabling preemption in rpl_output() is not good enough,
because rpl_output() is called from process context,
lwtunnel_output() only uses rcu_read_lock().

We might be interrupted by a softirq, re-enter rpl_output()
and corrupt dst_cache data structures.

Fix the race by using local_bh_disable() instead of
preempt_disable().

Apply a similar change in rpl_input().

Signed-off-by: Eric Dumazet <[email protected]>
Cc: Alexander Aring <[email protected]>
Acked-by: Paolo Abeni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoipv6: ioam: block BH from ioam6_output()
Eric Dumazet [Fri, 31 May 2024 13:26:32 +0000 (13:26 +0000)]
ipv6: ioam: block BH from ioam6_output()

As explained in commit 1378817486d6 ("tipc: block BH
before using dst_cache"), net/core/dst_cache.c
helpers need to be called with BH disabled.

Disabling preemption in ioam6_output() is not good enough,
because ioam6_output() is called from process context,
lwtunnel_output() only uses rcu_read_lock().

We might be interrupted by a softirq, re-enter ioam6_output()
and corrupt dst_cache data structures.

Fix the race by using local_bh_disable() instead of
preempt_disable().

Fixes: 8cb3bf8bff3c ("ipv6: ioam: Add support for the ip6ip6 encapsulation")
Signed-off-by: Eric Dumazet <[email protected]>
Cc: Justin Iurman <[email protected]>
Acked-by: Paolo Abeni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agovmxnet3: disable rx data ring on dma allocation failure
Matthias Stocker [Fri, 31 May 2024 10:37:11 +0000 (12:37 +0200)]
vmxnet3: disable rx data ring on dma allocation failure

When vmxnet3_rq_create() fails to allocate memory for rq->data_ring.base,
the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset
rq->data_ring.desc_size for the data ring that failed, which presumably
causes the hypervisor to reference it on packet reception.

To fix this bug, rq->data_ring.desc_size needs to be set to 0 to tell
the hypervisor to disable this feature.

[   95.436876] kernel BUG at net/core/skbuff.c:207!
[   95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[   95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1
[   95.441558] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018
[   95.443481] RIP: 0010:skb_panic+0x4d/0x4f
[   95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50
ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9
ff <0f> 0b 48 8b 14 24 48 c7 c1 d0 73 65 9f e8 a1 ff ff ff 48 8b 14 24
[   95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246
[   95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f
[   95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f
[   95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60
[   95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000
[   95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0
[   95.455682] FS:  0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000
[   95.457178] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0
[   95.459791] Call Trace:
[   95.460515]  <IRQ>
[   95.461180]  ? __die_body.cold+0x19/0x27
[   95.462150]  ? die+0x2e/0x50
[   95.462976]  ? do_trap+0xca/0x110
[   95.463973]  ? do_error_trap+0x6a/0x90
[   95.464966]  ? skb_panic+0x4d/0x4f
[   95.465901]  ? exc_invalid_op+0x50/0x70
[   95.466849]  ? skb_panic+0x4d/0x4f
[   95.467718]  ? asm_exc_invalid_op+0x1a/0x20
[   95.468758]  ? skb_panic+0x4d/0x4f
[   95.469655]  skb_put.cold+0x10/0x10
[   95.470573]  vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3]
[   95.471853]  vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3]
[   95.473185]  __napi_poll+0x2b/0x160
[   95.474145]  net_rx_action+0x2c6/0x3b0
[   95.475115]  handle_softirqs+0xe7/0x2a0
[   95.476122]  __irq_exit_rcu+0x97/0xb0
[   95.477109]  common_interrupt+0x85/0xa0
[   95.478102]  </IRQ>
[   95.478846]  <TASK>
[   95.479603]  asm_common_interrupt+0x26/0x40
[   95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20
[   95.481801] Code: 22 d7 e9 54 87 01 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa eb 07 0f 00 2d 93 ba 3b 00 fb f4 <e9> 2c 87 01 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90
[   95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246
[   95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000
[   95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001
[   95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3
[   95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260
[   95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000
[   95.495035]  acpi_safe_halt+0x14/0x20
[   95.496127]  acpi_idle_do_entry+0x2f/0x50
[   95.497221]  acpi_idle_enter+0x7f/0xd0
[   95.498272]  cpuidle_enter_state+0x81/0x420
[   95.499375]  cpuidle_enter+0x2d/0x40
[   95.500400]  do_idle+0x1e5/0x240
[   95.501385]  cpu_startup_entry+0x29/0x30
[   95.502422]  start_secondary+0x11c/0x140
[   95.503454]  common_startup_64+0x13e/0x141
[   95.504466]  </TASK>
[   95.505197] Modules linked in: nft_fib_inet nft_fib_ipv4
nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6
nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6
nf_defrag_ipv4 rfkill ip_set nf_tables vsock_loopback
vmw_vsock_virtio_transport_common qrtr vmw_vsock_vmci_transport vsock
sunrpc binfmt_misc pktcdvd vmw_balloon pcspkr vmw_vmci i2c_piix4 joydev
loop dm_multipath nfnetlink zram crct10dif_pclmul crc32_pclmul vmwgfx
crc32c_intel polyval_clmulni polyval_generic ghash_clmulni_intel
sha512_ssse3 sha256_ssse3 vmxnet3 sha1_ssse3 drm_ttm_helper vmw_pvscsi
ttm ata_generic pata_acpi serio_raw scsi_dh_rdac scsi_dh_emc
scsi_dh_alua ip6_tables ip_tables fuse
[   95.516536] ---[ end trace 0000000000000000 ]---

Fixes: 6f4833383e85 ("net: vmxnet3: Fix NULL pointer dereference in vmxnet3_rq_rx_complete()")
Signed-off-by: Matthias Stocker <[email protected]>
Reviewed-by: Subbaraya Sundeep <[email protected]>
Reviewed-by: Ronak Doshi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoMerge tag 'cxl-fixes-6.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl
Linus Torvalds [Mon, 3 Jun 2024 21:42:41 +0000 (14:42 -0700)]
Merge tag 'cxl-fixes-6.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl

Pull cxl fixes from Dave Jiang:

 - Compile fix for cxl-test from missing linux/vmalloc.h

 - Fix for memregion leaks in devm_cxl_add_region()

* tag 'cxl-fixes-6.10-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/cxl/cxl:
  cxl/region: Fix memregion leaks in devm_cxl_add_region()
  cxl/test: Add missing vmalloc.h for tools/testing/cxl/test/mem.c

9 months agotools headers uapi: Sync linux/stat.h with the kernel sources to pick STATX_SUBVOL
Arnaldo Carvalho de Melo [Wed, 29 May 2024 13:38:04 +0000 (10:38 -0300)]
tools headers uapi: Sync linux/stat.h with the kernel sources to pick STATX_SUBVOL

To pick the changes from:

  2a82bb02941fb53d ("statx: stx_subvol")

This silences this perf build warning:

  Warning: Kernel ABI header differences:
    diff -u tools/include/uapi/linux/stat.h include/uapi/linux/stat.h

Cc: Adrian Hunter <[email protected]>
Cc: Christian Brauner <[email protected]>
Cc: Ian Rogers <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Kan Liang <[email protected]>
Cc: Kent Overstreet <[email protected]>
Cc: Namhyung Kim <[email protected]>
Link: https://lore.kernel.org/lkml/ZlnK2Fmx_gahzwZI@x1
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
9 months agoMerge tag 'kvm-riscv-fixes-6.10-1' of https://github.com/kvm-riscv/linux into HEAD
Paolo Bonzini [Mon, 3 Jun 2024 17:18:18 +0000 (13:18 -0400)]
Merge tag 'kvm-riscv-fixes-6.10-1' of https://github.com/kvm-riscv/linux into HEAD

KVM/riscv fixes for 6.10, take #1

- No need to use mask when hart-index-bits is 0
- Fix incorrect reg_subtype labels in kvm_riscv_vcpu_set_reg_isa_ext()

9 months agoMerge branch 'kvm-fixes-6.10-1' into HEAD
Paolo Bonzini [Mon, 3 Jun 2024 17:09:55 +0000 (13:09 -0400)]
Merge branch 'kvm-fixes-6.10-1' into HEAD

* Fixes and debugging help for the #VE sanity check.  Also disable
  it by default, even for CONFIG_DEBUG_KERNEL, because it was found
  to trigger spuriously (most likely a processor erratum as the
  exact symptoms vary by generation).

* Avoid WARN() when two NMIs arrive simultaneously during an NMI-disabled
  situation (GIF=0 or interrupt shadow) when the processor supports
  virtual NMI.  While generally KVM will not request an NMI window
  when virtual NMIs are supported, in this case it *does* have to
  single-step over the interrupt shadow or enable the STGI intercept,
  in order to deliver the latched second NMI.

* Drop support for hand tuning APIC timer advancement from userspace.
  Since we have adaptive tuning, and it has proved to work well,
  drop the module parameter for manual configuration and with it a
  few stupid bugs that it had.

9 months agoKVM: x86: Drop support for hand tuning APIC timer advancement from userspace
Sean Christopherson [Wed, 22 May 2024 01:03:04 +0000 (18:03 -0700)]
KVM: x86: Drop support for hand tuning APIC timer advancement from userspace

Remove support for specifying a static local APIC timer advancement value,
and instead present a read-only boolean parameter to let userspace enable
or disable KVM's dynamic APIC timer advancement.  Realistically, it's all
but impossible for userspace to specify an advancement that is more
precise than what KVM's adaptive tuning can provide.  E.g. a static value
needs to be tuned for the exact hardware and kernel, and if KVM is using
hrtimers, likely requires additional tuning for the exact configuration of
the entire system.

Dropping support for a userspace provided value also fixes several flaws
in the interface.  E.g. KVM interprets a negative value other than -1 as a
large advancement, toggling between a negative and positive value yields
unpredictable behavior as vCPUs will switch from dynamic to static
advancement, changing the advancement in the middle of VM creation can
result in different values for vCPUs within a VM, etc.  Those flaws are
mostly fixable, but there's almost no justification for taking on yet more
complexity (it's minimal complexity, but still non-zero).

The only arguments against using KVM's adaptive tuning is if a setup needs
a higher maximum, or if the adjustments are too reactive, but those are
arguments for letting userspace control the absolute max advancement and
the granularity of each adjustment, e.g. similar to how KVM provides knobs
for halt polling.

Link: https://lore.kernel.org/all/[email protected]
Cc: Shuling Zhou <[email protected]>
Cc: Marcelo Tosatti <[email protected]>
Signed-off-by: Sean Christopherson <[email protected]>
Message-ID: <20240522010304.1650603[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
9 months agoKVM: SEV-ES: Delegate LBR virtualization to the processor
Ravi Bangoria [Fri, 31 May 2024 04:46:44 +0000 (04:46 +0000)]
KVM: SEV-ES: Delegate LBR virtualization to the processor

As documented in APM[1], LBR Virtualization must be enabled for SEV-ES
guests. Although KVM currently enforces LBRV for SEV-ES guests, there
are multiple issues with it:

o MSR_IA32_DEBUGCTLMSR is still intercepted. Since MSR_IA32_DEBUGCTLMSR
  interception is used to dynamically toggle LBRV for performance reasons,
  this can be fatal for SEV-ES guests. For ex SEV-ES guest on Zen3:

  [guest ~]# wrmsr 0x1d9 0x4
  KVM: entry failed, hardware error 0xffffffff
  EAX=00000004 EBX=00000000 ECX=000001d9 EDX=00000000

  Fix this by never intercepting MSR_IA32_DEBUGCTLMSR for SEV-ES guests.
  No additional save/restore logic is required since MSR_IA32_DEBUGCTLMSR
  is of swap type A.

o KVM will disable LBRV if userspace sets MSR_IA32_DEBUGCTLMSR before the
  VMSA is encrypted. Fix this by moving LBRV enablement code post VMSA
  encryption.

[1]: AMD64 Architecture Programmer's Manual Pub. 40332, Rev. 4.07 - June
     2023, Vol 2, 15.35.2 Enabling SEV-ES.
     https://bugzilla.kernel.org/attachment.cgi?id=304653

Fixes: 376c6d285017 ("KVM: SVM: Provide support for SEV-ES vCPU creation/loading")
Co-developed-by: Nikunj A Dadhania <[email protected]>
Signed-off-by: Nikunj A Dadhania <[email protected]>
Signed-off-by: Ravi Bangoria <[email protected]>
Message-ID: <20240531044644[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
9 months agoKVM: SEV-ES: Disallow SEV-ES guests when X86_FEATURE_LBRV is absent
Ravi Bangoria [Fri, 31 May 2024 04:46:43 +0000 (04:46 +0000)]
KVM: SEV-ES: Disallow SEV-ES guests when X86_FEATURE_LBRV is absent

As documented in APM[1], LBR Virtualization must be enabled for SEV-ES
guests. So, prevent SEV-ES guests when LBRV support is missing.

[1]: AMD64 Architecture Programmer's Manual Pub. 40332, Rev. 4.07 - June
     2023, Vol 2, 15.35.2 Enabling SEV-ES.
     https://bugzilla.kernel.org/attachment.cgi?id=304653

Fixes: 376c6d285017 ("KVM: SVM: Provide support for SEV-ES vCPU creation/loading")
Signed-off-by: Ravi Bangoria <[email protected]>
Message-ID: <20240531044644[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
9 months agoKVM: SEV-ES: Prevent MSR access post VMSA encryption
Nikunj A Dadhania [Fri, 31 May 2024 04:46:42 +0000 (04:46 +0000)]
KVM: SEV-ES: Prevent MSR access post VMSA encryption

KVM currently allows userspace to read/write MSRs even after the VMSA is
encrypted. This can cause unintentional issues if MSR access has side-
effects. For ex, while migrating a guest, userspace could attempt to
migrate MSR_IA32_DEBUGCTLMSR and end up unintentionally disabling LBRV on
the target. Fix this by preventing access to those MSRs which are context
switched via the VMSA, once the VMSA is encrypted.

Suggested-by: Sean Christopherson <[email protected]>
Signed-off-by: Nikunj A Dadhania <[email protected]>
Signed-off-by: Ravi Bangoria <[email protected]>
Message-ID: <20240531044644[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
9 months agoMerge tag 'loongarch-fixes-6.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Mon, 3 Jun 2024 16:27:45 +0000 (09:27 -0700)]
Merge tag 'loongarch-fixes-6.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson

Pull LoongArch fixes from Huacai Chen:
 "Some bootloader interface fixes, a dts fix, and a trivial cleanup"

* tag 'loongarch-fixes-6.10-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson:
  LoongArch: Fix GMAC's phy-mode definitions in dts
  LoongArch: Override higher address bits in JUMP_VIRT_ADDR
  LoongArch: Fix entry point in kernel image header
  LoongArch: Add all CPUs enabled by fdt to NUMA node 0
  LoongArch: Fix built-in DTB detection
  LoongArch: Remove CONFIG_ACPI_TABLE_UPGRADE in platform_init()

9 months agoirqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()
Hagar Hemdan [Fri, 31 May 2024 16:21:44 +0000 (16:21 +0000)]
irqchip/gic-v3-its: Fix potential race condition in its_vlpi_prop_update()

its_vlpi_prop_update() calls lpi_write_config() which obtains the
mapping information for a VLPI without lock held. So it could race
with its_vlpi_unmap().

Since all calls from its_irq_set_vcpu_affinity() require the same
lock to be held, hoist the locking there instead of sprinkling the
locking all over the place.

This bug was discovered using Coverity Static Analysis Security Testing
(SAST) by Synopsys, Inc.

[ tglx: Use guard() instead of goto ]

Fixes: 015ec0386ab6 ("irqchip/gic-v3-its: Add VLPI configuration handling")
Suggested-by: Marc Zyngier <[email protected]>
Signed-off-by: Hagar Hemdan <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Cc: [email protected]
Reviewed-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
9 months agobpf: Fix a potential use-after-free in bpf_link_free()
Cong Wang [Sun, 2 Jun 2024 18:27:03 +0000 (11:27 -0700)]
bpf: Fix a potential use-after-free in bpf_link_free()

After commit 1a80dbcb2dba, bpf_link can be freed by
link->ops->dealloc_deferred, but the code still tests and uses
link->ops->dealloc afterward, which leads to a use-after-free as
reported by syzbot. Actually, one of them should be sufficient, so
just call one of them instead of both. Also add a WARN_ON() in case
of any problematic implementation.

Fixes: 1a80dbcb2dba ("bpf: support deferring bpf_link dealloc to after RCU grace period")
Reported-by: [email protected]
Signed-off-by: Cong Wang <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
9 months agocpufreq: intel_pstate: Fix unchecked HWP MSR access
Srinivas Pandruvada [Fri, 31 May 2024 23:00:04 +0000 (16:00 -0700)]
cpufreq: intel_pstate: Fix unchecked HWP MSR access

Fix unchecked MSR access error for processors with no HWP support. On
such processors, maximum frequency can be changed by the system firmware
using ACPI event ACPI_PROCESSOR_NOTIFY_HIGEST_PERF_CHANGED. This results
in accessing HWP MSR 0x771.

Call Trace:
<TASK>
generic_exec_single+0x58/0x120
smp_call_function_single+0xbf/0x110
rdmsrl_on_cpu+0x46/0x60
intel_pstate_get_hwp_cap+0x1b/0x70
intel_pstate_update_limits+0x2a/0x60
acpi_processor_notify+0xb7/0x140
acpi_ev_notify_dispatch+0x3b/0x60

HWP MSR 0x771 can be only read on a CPU which supports HWP and enabled.
Hence intel_pstate_get_hwp_cap() can only be called when hwp_active is
true.

Reported-by: Sebastian Andrzej Siewior <[email protected]>
Closes: https://lore.kernel.org/linux-pm/[email protected]/
Fixes: e8217b4bece3 ("cpufreq: intel_pstate: Update the maximum CPU frequency consistently")
Tested-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
9 months agox86/kexec: Fix bug with call depth tracking
David Kaplan [Sun, 2 Jun 2024 18:19:09 +0000 (13:19 -0500)]
x86/kexec: Fix bug with call depth tracking

The call to cc_platform_has() triggers a fault and system crash if call depth
tracking is active because the GS segment has been reset by load_segments() and
GS_BASE is now 0 but call depth tracking uses per-CPU variables to operate.

Call cc_platform_has() earlier in the function when GS is still valid.

  [ bp: Massage. ]

Fixes: 5d8213864ade ("x86/retbleed: Add SKL return thunk")
Signed-off-by: David Kaplan <[email protected]>
Signed-off-by: Borislav Petkov (AMD) <[email protected]>
Reviewed-by: Tom Lendacky <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
9 months agobpf, devmap: Remove unnecessary if check in for loop
Thorsten Blum [Wed, 29 May 2024 10:19:01 +0000 (12:19 +0200)]
bpf, devmap: Remove unnecessary if check in for loop

The iterator variable dst cannot be NULL and the if check can be removed.
Remove it and fix the following Coccinelle/coccicheck warning reported
by itnull.cocci:

ERROR: iterator variable bound on line 762 cannot be NULL

Signed-off-by: Thorsten Blum <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Reviewed-by: Toke Høiland-Jørgensen <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
9 months agoRevert "riscv: mm: accelerate pagefault when badaccess"
Palmer Dabbelt [Thu, 30 May 2024 16:44:51 +0000 (09:44 -0700)]
Revert "riscv: mm: accelerate pagefault when badaccess"

I accidentally picked up an earlier version of this patch, which had
already landed via mm.  The patch  I picked up contains a bug, which I
kept as I thought it was a fix.  So let's just revert it.

This reverts commit 4c6c0020427a4547845a83f7e4d6085e16c3e24f.

Fixes: 4c6c0020427a ("riscv: mm: accelerate pagefault when badaccess")
Reviewed-by: Kefeng Wang <[email protected]>
Reviewed-by: Alexandre Ghiti <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>
9 months agoriscv: fix overlap of allocated page and PTR_ERR
Nam Cao [Thu, 25 Apr 2024 11:52:01 +0000 (13:52 +0200)]
riscv: fix overlap of allocated page and PTR_ERR

On riscv32, it is possible for the last page in virtual address space
(0xfffff000) to be allocated. This page overlaps with PTR_ERR, so that
shouldn't happen.

There is already some code to ensure memblock won't allocate the last page.
However, buddy allocator is left unchecked.

Fix this by reserving physical memory that would be mapped at virtual
addresses greater than 0xfffff000.

Reported-by: Björn Töpel <[email protected]>
Closes: https://lore.kernel.org/linux-riscv/[email protected]
Fixes: 76d2a0493a17 ("RISC-V: Init and Halt Code")
Signed-off-by: Nam Cao <[email protected]>
Cc: <[email protected]>
Tested-by: Björn Töpel <[email protected]>
Reviewed-by: Björn Töpel <[email protected]>
Reviewed-by: Mike Rapoport (IBM) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>
9 months agotomoyo: update project links
Tetsuo Handa [Mon, 3 Jun 2024 13:43:11 +0000 (22:43 +0900)]
tomoyo: update project links

TOMOYO project has moved to SourceForge.net .

Signed-off-by: Tetsuo Handa <[email protected]>
9 months agoSUNRPC: Fix loop termination condition in gss_free_in_token_pages()
Chuck Lever [Sun, 2 Jun 2024 22:15:25 +0000 (18:15 -0400)]
SUNRPC: Fix loop termination condition in gss_free_in_token_pages()

The in_token->pages[] array is not NULL terminated. This results in
the following KASAN splat:

  KASAN: maybe wild-memory-access in range [0x04a2013400000008-0x04a201340000000f]

Fixes: bafa6b4d95d9 ("SUNRPC: Fix gss_free_in_token_pages()")
Reviewed-by: Benjamin Coddington <[email protected]>
Signed-off-by: Chuck Lever <[email protected]>
9 months agogpio: tqmx86: fix broken IRQ_TYPE_EDGE_BOTH interrupt type
Matthias Schiffer [Thu, 30 May 2024 10:20:02 +0000 (12:20 +0200)]
gpio: tqmx86: fix broken IRQ_TYPE_EDGE_BOTH interrupt type

The TQMx86 GPIO controller only supports falling and rising edge
triggers, but not both. Fix this by implementing a software both-edge
mode that toggles the edge type after every interrupt.

Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
Co-developed-by: Gregor Herburger <[email protected]>
Signed-off-by: Gregor Herburger <[email protected]>
Signed-off-by: Matthias Schiffer <[email protected]>
Link: https://lore.kernel.org/r/515324f0491c4d44f4ef49f170354aca002d81ef.1717063994.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Bartosz Golaszewski <[email protected]>
9 months agogpio: tqmx86: store IRQ trigger type and unmask status separately
Matthias Schiffer [Thu, 30 May 2024 10:20:01 +0000 (12:20 +0200)]
gpio: tqmx86: store IRQ trigger type and unmask status separately

irq_set_type() should not implicitly unmask the IRQ.

All accesses to the interrupt configuration register are moved to a new
helper tqmx86_gpio_irq_config(). We also introduce the new rule that
accessing irq_type must happen while locked, which will become
significant for fixing EDGE_BOTH handling.

Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
Signed-off-by: Matthias Schiffer <[email protected]>
Link: https://lore.kernel.org/r/6aa4f207f77cb58ef64ffb947e91949b0f753ccd.1717063994.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Bartosz Golaszewski <[email protected]>
9 months agogpio: tqmx86: introduce shadow register for GPIO output value
Matthias Schiffer [Thu, 30 May 2024 10:20:00 +0000 (12:20 +0200)]
gpio: tqmx86: introduce shadow register for GPIO output value

The TQMx86 GPIO controller uses the same register address for input and
output data. Reading the register will always return current inputs
rather than the previously set outputs (regardless of the current
direction setting). Therefore, using a RMW pattern does not make sense
when setting output values. Instead, the previously set output register
value needs to be stored as a shadow register.

As there is no reliable way to get the current output values from the
hardware, also initialize all channels to 0, to ensure that stored and
actual output values match. This should usually not have any effect in
practise, as the TQMx86 UEFI sets all outputs to 0 during boot.

Also prepare for extension of the driver to more than 8 GPIOs by using
DECLARE_BITMAP.

Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
Signed-off-by: Matthias Schiffer <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Link: https://lore.kernel.org/r/d0555933becd45fa92a85675d26e4d59343ddc01.1717063994.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Bartosz Golaszewski <[email protected]>
9 months agogpio: tqmx86: fix typo in Kconfig label
Gregor Herburger [Thu, 30 May 2024 10:19:59 +0000 (12:19 +0200)]
gpio: tqmx86: fix typo in Kconfig label

Fix description for GPIO_TQMX86 from QTMX86 to TQMx86.

Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
Signed-off-by: Gregor Herburger <[email protected]>
Signed-off-by: Matthias Schiffer <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Link: https://lore.kernel.org/r/e0e38c9944ad6d281d9a662a45d289b88edc808e.1717063994.git.matthias.schiffer@ew.tq-group.com
Signed-off-by: Bartosz Golaszewski <[email protected]>
9 months agoirqchip/sifive-plic: Chain to parent IRQ after handlers are ready
Samuel Holland [Wed, 29 May 2024 21:54:56 +0000 (14:54 -0700)]
irqchip/sifive-plic: Chain to parent IRQ after handlers are ready

Now that the PLIC uses a platform driver, the driver is probed later in the
boot process, where interrupts from peripherals might already be pending.

As a result, plic_handle_irq() may be called as early as the call to
irq_set_chained_handler() completes. But this call happens before the
per-context handler is completely set up, so there is a window where
plic_handle_irq() can see incomplete per-context state and crash.

Avoid this by delaying the call to irq_set_chained_handler() until all
handlers from all PLICs are initialized.

Fixes: 8ec99b033147 ("irqchip/sifive-plic: Convert PLIC driver into a platform driver")
Reported-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Samuel Holland <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Anup Patel <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Closes: https://lore.kernel.org/r/CAMuHMdVYFFR7K5SbHBLY-JHhb7YpgGMS_hnRWm8H0KD-wBo+4A@mail.gmail.com/
9 months agonet: phy: micrel: fix KSZ9477 PHY issues after suspend/resume
Tristram Ha [Wed, 29 May 2024 02:20:23 +0000 (19:20 -0700)]
net: phy: micrel: fix KSZ9477 PHY issues after suspend/resume

When the PHY is powered up after powered down most of the registers are
reset, so the PHY setup code needs to be done again.  In addition the
interrupt register will need to be setup again so that link status
indication works again.

Fixes: 26dd2974c5b5 ("net: phy: micrel: Move KSZ9477 errata fixes to PHY driver")
Signed-off-by: Tristram Ha <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
9 months agoirqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails
Sunil V L [Mon, 27 May 2024 08:11:13 +0000 (13:41 +0530)]
irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails

When riscv_intc_init_common() fails, the firmware node allocated is not
freed. Add the missing free().

Fixes: 7023b9d83f03 ("irqchip/riscv-intc: Add ACPI support")
Signed-off-by: Sunil V L <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Anup Patel <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
9 months agoplatform/x86/amd/hsmp: Check HSMP support on AMD family of processors
Suma Hegde [Mon, 3 Jun 2024 08:15:12 +0000 (08:15 +0000)]
platform/x86/amd/hsmp: Check HSMP support on AMD family of processors

HSMP interface is supported only on few x86 processors from AMD.
Accessing HSMP registers on rest of the platforms might cause
unexpected behaviour. So add a check.

Also unavailability of this interface on rest of the processors
is not an error. Hence, use pr_info() instead of the pr_err() to
log the message.

Signed-off-by: Suma Hegde <[email protected]>
Reviewed-by: Naveen Krishna Chatradhi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
9 months agoplatform/x86: dell-smbios: Simplify error handling
Armin Wolf [Tue, 28 May 2024 20:49:03 +0000 (22:49 +0200)]
platform/x86: dell-smbios: Simplify error handling

When the allocation of value_name fails, the error handling code
uses two gotos for error handling, which is not necessary.

Simplify the error handling in this case by only using a single goto.

Tested on a Dell Inspiron 3505.

Signed-off-by: Armin Wolf <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
9 months agoplatform/x86: dell-smbios: Fix wrong token data in sysfs
Armin Wolf [Tue, 28 May 2024 20:49:02 +0000 (22:49 +0200)]
platform/x86: dell-smbios: Fix wrong token data in sysfs

When reading token data from sysfs on my Inspiron 3505, the token
locations and values are wrong. This happens because match_attribute()
blindly assumes that all entries in da_tokens have an associated
entry in token_attrs.

This however is not true as soon as da_tokens[] contains zeroed
token entries. Those entries are being skipped when initialising
token_attrs, breaking the core assumption of match_attribute().

Fix this by defining an extra struct for each pair of token attributes
and use container_of() to retrieve token information.

Tested on a Dell Inspiron 3050.

Fixes: 33b9ca1e53b4 ("platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens")
Signed-off-by: Armin Wolf <[email protected]>
Reviewed-by: Ilpo Järvinen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
9 months agoplatform/x86: yt2-1380: add CONFIG_EXTCON dependency
Arnd Bergmann [Tue, 28 May 2024 11:59:33 +0000 (13:59 +0200)]
platform/x86: yt2-1380: add CONFIG_EXTCON dependency

This driver uses the extcon subsystem and fails to build
when it cannot call into that subsystem:

x86_64-linux-ld: vmlinux.o: in function `yt2_1380_fc_worker':
lenovo-yoga-tab2-pro-1380-fastcharger.c:(.text+0xa9d819): undefined reference to `extcon_get_state'
x86_64-linux-ld: lenovo-yoga-tab2-pro-1380-fastcharger.c:(.text+0xa9d853): undefined reference to `extcon_get_state'
x86_64-linux-ld: vmlinux.o: in function `yt2_1380_fc_serdev_probe':
lenovo-yoga-tab2-pro-1380-fastcharger.c:(.text+0xa9da22): undefined reference to `extcon_get_extcon_dev'
x86_64-linux-ld: lenovo-yoga-tab2-pro-1380-fastcharger.c:(.text+0xa9dc0c): undefined reference to `devm_extcon_register_notifier_all'

Add a Kconfig dependency to make it it always builds correctly.

Fixes: b2ed33e8d486 ("platform/x86: Add lenovo-yoga-tab2-pro-1380-fastcharger driver")
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
9 months agoplatform/x86: touchscreen_dmi: Use 2-argument strscpy()
Andy Shevchenko [Sun, 2 Jun 2024 08:58:00 +0000 (11:58 +0300)]
platform/x86: touchscreen_dmi: Use 2-argument strscpy()

Use 2-argument strscpy(), which is not only shorter but also provides
an additional check that destination buffer is an array.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
9 months agoplatform/x86: touchscreen_dmi: Drop "silead,max-fingers" property
Hans de Goede [Sat, 25 May 2024 19:38:54 +0000 (21:38 +0200)]
platform/x86: touchscreen_dmi: Drop "silead,max-fingers" property

The silead touchscreen driver now defaults to 10 fingers, so it is no
longer necessary to have a "silead,max-fingers=10" property for each
silead touchscreen model. Drop this property from all the configs.

Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
9 months agoInput: silead - Always support 10 fingers
Hans de Goede [Sat, 25 May 2024 19:38:53 +0000 (21:38 +0200)]
Input: silead - Always support 10 fingers

When support for Silead touchscreens was orginal added some touchscreens
with older firmware versions only supported 5 fingers and this was made
the default requiring the setting of a "silead,max-fingers=10" uint32
device-property for all touchscreen models which do support 10 fingers.

There are very few models with the old 5 finger fw, so in practice the
setting of the "silead,max-fingers=10" is boilerplate which needs to
be copy and pasted to every touchscreen config.

Reporting that 10 fingers are supported on devices which only support
5 fingers doesn't cause any problems for userspace in practice, since
at max 4 finger gestures are supported anyways. Drop the max_fingers
configuration and simply always assume 10 fingers.

Signed-off-by: Hans de Goede <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
9 months agodrm/panel: sitronix-st7789v: Add check for of_drm_get_panel_orientation
Chen Ni [Tue, 28 May 2024 03:08:32 +0000 (11:08 +0800)]
drm/panel: sitronix-st7789v: Add check for of_drm_get_panel_orientation

Add check for the return value of of_drm_get_panel_orientation() and
return the error if it fails in order to catch the error.

Fixes: b27c0f6d208d ("drm/panel: sitronix-st7789v: add panel orientation support")
Signed-off-by: Chen Ni <[email protected]>
Reviewed-by: Michael Riesch <[email protected]>
Acked-by: Jessica Zhang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
9 months agoLoongArch: Fix GMAC's phy-mode definitions in dts
Huacai Chen [Mon, 3 Jun 2024 07:45:53 +0000 (15:45 +0800)]
LoongArch: Fix GMAC's phy-mode definitions in dts

The GMAC of Loongson chips cannot insert the correct 1.5-2ns delay. So
we need the PHY to insert internal delays for both transmit and receive
data lines from/to the PHY device. Fix this by changing the "phy-mode"
from "rgmii" to "rgmii-id" in dts.

Signed-off-by: Huacai Chen <[email protected]>
9 months agoLoongArch: Override higher address bits in JUMP_VIRT_ADDR
Jiaxun Yang [Mon, 3 Jun 2024 07:45:53 +0000 (15:45 +0800)]
LoongArch: Override higher address bits in JUMP_VIRT_ADDR

In JUMP_VIRT_ADDR we are performing an or calculation on address value
directly from pcaddi.

This will only work if we are currently running from direct 1:1 mapping
addresses or firmware's DMW is configured exactly same as kernel. Still,
we should not rely on such assumption.

Fix by overriding higher bits in address comes from pcaddi, so we can
get rid of or operator.

Cc: [email protected]
Signed-off-by: Jiaxun Yang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
9 months agoLoongArch: Fix entry point in kernel image header
Jiaxun Yang [Mon, 3 Jun 2024 07:45:53 +0000 (15:45 +0800)]
LoongArch: Fix entry point in kernel image header

Currently kernel entry in head.S is in DMW address range, firmware is
instructed to jump to this address after loading the kernel image.

However kernel should not make any assumption on firmware's DMW
setting, thus the entry point should be a physical address falls into
direct translation region.

Fix by converting entry address to physical and amend entry calculation
logic in libstub accordingly.

BTW, use ABSOLUTE() to calculate variables to make Clang/LLVM happy.

Cc: [email protected]
Signed-off-by: Jiaxun Yang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
9 months agoLoongArch: Add all CPUs enabled by fdt to NUMA node 0
Jiaxun Yang [Mon, 3 Jun 2024 07:45:53 +0000 (15:45 +0800)]
LoongArch: Add all CPUs enabled by fdt to NUMA node 0

NUMA enabled kernel on FDT based machine fails to boot because CPUs
are all in NUMA_NO_NODE and mm subsystem won't accept that.

Fix by adding them to default NUMA node at FDT parsing phase and move
numa_add_cpu(0) to a later point.

Cc: [email protected]
Fixes: 88d4d957edc7 ("LoongArch: Add FDT booting support from efi system table")
Signed-off-by: Jiaxun Yang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
9 months agoLoongArch: Fix built-in DTB detection
Jiaxun Yang [Mon, 3 Jun 2024 07:45:53 +0000 (15:45 +0800)]
LoongArch: Fix built-in DTB detection

fdt_check_header(__dtb_start) will always success because kernel
provides a dummy dtb, and by coincidence __dtb_start clashed with
entry of this dummy dtb. The consequence is fdt passed from firmware
will never be taken.

Fix by trying to utilise __dtb_start only when CONFIG_BUILTIN_DTB is
enabled.

Cc: [email protected]
Fixes: 7b937cc243e5 ("of: Create of_root if no dtb provided by firmware")
Signed-off-by: Jiaxun Yang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
9 months agoLoongArch: Remove CONFIG_ACPI_TABLE_UPGRADE in platform_init()
Tiezhu Yang [Mon, 3 Jun 2024 07:45:53 +0000 (15:45 +0800)]
LoongArch: Remove CONFIG_ACPI_TABLE_UPGRADE in platform_init()

Both acpi_table_upgrade() and acpi_boot_table_init() are defined as
empty functions under !CONFIG_ACPI_TABLE_UPGRADE and !CONFIG_ACPI in
include/linux/acpi.h, there are no implicit declaration errors with
various configs.

  #ifdef CONFIG_ACPI_TABLE_UPGRADE
  void acpi_table_upgrade(void);
  #else
  static inline void acpi_table_upgrade(void) { }
  #endif

  #ifdef CONFIG_ACPI
  ...
  void acpi_boot_table_init (void);
  ...
  #else /* !CONFIG_ACPI */
  ...
  static inline void acpi_boot_table_init(void)
  {
  }
  ...
  #endif /* !CONFIG_ACPI */

As Huacai suggested, CONFIG_ACPI_TABLE_UPGRADE is ugly and not necessary
here, just remove it. At the same time, just keep CONFIG_ACPI to prevent
potential build errors in future, and give a signal to indicate the code
is ACPI-specific. For the same reason, we also put acpi_table_upgrade()
under CONFIG_ACPI.

Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>
9 months agoMerge tag 'i2c-host-6.10-pt2' of git://git.kernel.org/pub/scm/linux/kernel/git/andi...
Wolfram Sang [Mon, 3 Jun 2024 06:51:53 +0000 (08:51 +0200)]
Merge tag 'i2c-host-6.10-pt2' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux into i2c/for-current

Removed the SPD class of i2c devices from the device core.

Additionally, a cleanup in the Synquacer code removes the pclk
from the global structure, as it is used only in the probe.
Therefore, it is now declared locally.

9 months agoLinux 6.10-rc2 v6.10-rc2
Linus Torvalds [Sun, 2 Jun 2024 22:44:56 +0000 (15:44 -0700)]
Linux 6.10-rc2

9 months agoMerge tag 'ata-6.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata...
Linus Torvalds [Sun, 2 Jun 2024 20:30:53 +0000 (13:30 -0700)]
Merge tag 'ata-6.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux

Pull ata fixes from Niklas Cassel:

 - Add a quirk for three different devices that have shown issues with
   LPM (link power management). These devices appear to not implement
   LPM properly, since we see command timeouts when enabling LPM. The
   quirk disables LPM for these problematic devices. (Me)

 - Do not apply the Intel PCS quirk on Alder Lake. The quirk is not
   needed and was originally added by mistake when LPM support was
   enabled for this AHCI controller. Enabling the quirk when not needed
   causes the the controller to not be able to detect the connected
   devices on some platforms.

* tag 'ata-6.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
  ata: libata-core: Add ATA_HORKAGE_NOLPM for Apacer AS340
  ata: libata-core: Add ATA_HORKAGE_NOLPM for AMD Radeon S3 SSD
  ata: libata-core: Add ATA_HORKAGE_NOLPM for Crucial CT240BX500SSD1
  ata: ahci: Do not apply Intel PCS quirk on Intel Alder Lake

9 months agoMerge tag 'x86-urgent-2024-06-02' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Sun, 2 Jun 2024 16:32:34 +0000 (09:32 -0700)]
Merge tag 'x86-urgent-2024-06-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:
 "Miscellaneous topology parsing fixes:

   - Fix topology parsing regression on older CPUs in the new AMD/Hygon
     parser

   - Fix boot crash on odd Intel Quark and similar CPUs that do not fill
     out cpuinfo_x86::x86_clflush_size and zero out
     cpuinfo_x86::x86_cache_alignment as a result.

     Provide 32 bytes as a general fallback value.

   - Fix topology enumeration on certain rare CPUs where the BIOS locks
     certain CPUID leaves and the kernel unlocked them late, which broke
     with the new topology parsing code. Factor out this unlocking logic
     and move it earlier in the parsing sequence"

* tag 'x86-urgent-2024-06-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/topology/intel: Unlock CPUID before evaluating anything
  x86/cpu: Provide default cache line size if not enumerated
  x86/topology/amd: Evaluate SMT in CPUID leaf 0x8000001e only on family 0x17 and greater

9 months agoMerge tag 'sched-urgent-2024-06-02' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 2 Jun 2024 16:23:35 +0000 (09:23 -0700)]
Merge tag 'sched-urgent-2024-06-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull scheduler fix from Ingo Molnar:
 "Export a symbol to make life easier for instrumentation/debugging"

* tag 'sched-urgent-2024-06-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/x86: Export 'percpu arch_freq_scale'

9 months agoMerge tag 'perf-urgent-2024-06-02' of git://git.kernel.org/pub/scm/linux/kernel/git...
Linus Torvalds [Sun, 2 Jun 2024 16:20:37 +0000 (09:20 -0700)]
Merge tag 'perf-urgent-2024-06-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull perf events fix from Ingo Molnar:
 "Add missing MODULE_DESCRIPTION() lines"

* tag 'perf-urgent-2024-06-02' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/intel: Add missing MODULE_DESCRIPTION() lines
  perf/x86/rapl: Add missing MODULE_DESCRIPTION() line

9 months agoMerge tag 'hardening-v6.10-rc2-take2' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 2 Jun 2024 16:15:28 +0000 (09:15 -0700)]
Merge tag 'hardening-v6.10-rc2-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

Pull hardening fixes from Kees Cook:

 - scsi: mpt3sas: Avoid possible run-time warning with long manufacturer
   strings

 - mailmap: update entry for Kees Cook

 - kunit/fortify: Remove __kmalloc_node() test

* tag 'hardening-v6.10-rc2-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  kunit/fortify: Remove __kmalloc_node() test
  mailmap: update entry for Kees Cook
  scsi: mpt3sas: Avoid possible run-time warning with long manufacturer strings

9 months agoMerge tag 'powerpc-6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc...
Linus Torvalds [Sun, 2 Jun 2024 00:34:35 +0000 (17:34 -0700)]
Merge tag 'powerpc-6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:

 - Enforce full ordering for ATOMIC operations with BPF_FETCH

 - Fix uaccess build errors seen with GCC 13/14

 - Fix build errors on ppc32 due to ARCH_HAS_KERNEL_FPU_SUPPORT

 - Drop error message from lparcfg guest name lookup

Thanks to Christophe Leroy, Guenter Roeck, Nathan Lynch, Naveen N Rao,
Puranjay Mohan, and Samuel Holland.

* tag 'powerpc-6.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc: Limit ARCH_HAS_KERNEL_FPU_SUPPORT to PPC64
  powerpc/uaccess: Use YZ asm constraint for ld
  powerpc/uaccess: Fix build errors seen with GCC 13/14
  powerpc/pseries/lparcfg: drop error message from guest name lookup
  powerpc/bpf: enforce full ordering for ATOMIC operations with BPF_FETCH

9 months agoMerge tag 'firewire-fixes-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Sun, 2 Jun 2024 00:05:00 +0000 (17:05 -0700)]
Merge tag 'firewire-fixes-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394

Pull firewire fix from Takashi Sakamoto:
 "After merging a commit 1fffe7a34c89 ("script: modpost: emit a warning
  when the description is missing"), MODULE_DESCRIPTOR seems to be
  mandatory for kernel modules. In FireWire subsystem, the most of
  practical kernel modules have the field, while KUnit test modules do
  not. A single patch is applied to fix them"

* tag 'firewire-fixes-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
  firewire: add missing MODULE_DESCRIPTION() to test modules

9 months agonet/tcp: Don't consider TCP_CLOSE in TCP_AO_ESTABLISHED
Dmitry Safonov [Wed, 29 May 2024 17:29:32 +0000 (18:29 +0100)]
net/tcp: Don't consider TCP_CLOSE in TCP_AO_ESTABLISHED

TCP_CLOSE may or may not have current/rnext keys and should not be
considered "established". The fast-path for TCP_CLOSE is
SKB_DROP_REASON_TCP_CLOSE. This is what tcp_rcv_state_process() does
anyways. Add an early drop path to not spend any time verifying
segment signatures for sockets in TCP_CLOSE state.

Cc: [email protected] # v6.7
Fixes: 0a3a809089eb ("net/tcp: Verify inbound TCP-AO signed segments")
Signed-off-by: Dmitry Safonov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agonet/ncsi: Fix the multi thread manner of NCSI driver
DelphineCCChiu [Wed, 29 May 2024 06:58:55 +0000 (14:58 +0800)]
net/ncsi: Fix the multi thread manner of NCSI driver

Currently NCSI driver will send several NCSI commands back to back without
waiting the response of previous NCSI command or timeout in some state
when NIC have multi channel. This operation against the single thread
manner defined by NCSI SPEC(section 6.3.2.3 in DSP0222_1.1.1)

According to NCSI SPEC(section 6.2.13.1 in DSP0222_1.1.1), we should probe
one channel at a time by sending NCSI commands (Clear initial state, Get
version ID, Get capabilities...), than repeat this steps until the max
number of channels which we got from NCSI command (Get capabilities) has
been probed.

Fixes: e6f44ed6d04d ("net/ncsi: Package and channel management")
Signed-off-by: DelphineCCChiu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agonet: rps: fix error when CONFIG_RFS_ACCEL is off
Jason Xing [Thu, 30 May 2024 03:27:17 +0000 (11:27 +0800)]
net: rps: fix error when CONFIG_RFS_ACCEL is off

John Sperbeck reported that if we turn off CONFIG_RFS_ACCEL, the 'head'
is not defined, which will trigger compile error. So I move the 'head'
out of the CONFIG_RFS_ACCEL scope.

Fixes: 84b6823cd96b ("net: rps: protect last_qtail with rps_input_queue_tail_save() helper")
Reported-by: John Sperbeck <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Jason Xing <[email protected]>
Reviewed-by: Eric Dumazet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoax25: Replace kfree() in ax25_dev_free() with ax25_dev_put()
Duoming Zhou [Thu, 30 May 2024 05:17:33 +0000 (13:17 +0800)]
ax25: Replace kfree() in ax25_dev_free() with ax25_dev_put()

The object "ax25_dev" is managed by reference counting. Thus it should
not be directly released by kfree(), replace with ax25_dev_put().

Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs")
Suggested-by: Dan Carpenter <[email protected]>
Signed-off-by: Duoming Zhou <[email protected]>
Reviewed-by: Dan Carpenter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoax25: Fix refcount imbalance on inbound connections
Lars Kellogg-Stedman [Wed, 29 May 2024 21:02:43 +0000 (17:02 -0400)]
ax25: Fix refcount imbalance on inbound connections

When releasing a socket in ax25_release(), we call netdev_put() to
decrease the refcount on the associated ax.25 device. However, the
execution path for accepting an incoming connection never calls
netdev_hold(). This imbalance leads to refcount errors, and ultimately
to kernel crashes.

A typical call trace for the above situation will start with one of the
following errors:

    refcount_t: decrement hit 0; leaking memory.
    refcount_t: underflow; use-after-free.

And will then have a trace like:

    Call Trace:
    <TASK>
    ? show_regs+0x64/0x70
    ? __warn+0x83/0x120
    ? refcount_warn_saturate+0xb2/0x100
    ? report_bug+0x158/0x190
    ? prb_read_valid+0x20/0x30
    ? handle_bug+0x3e/0x70
    ? exc_invalid_op+0x1c/0x70
    ? asm_exc_invalid_op+0x1f/0x30
    ? refcount_warn_saturate+0xb2/0x100
    ? refcount_warn_saturate+0xb2/0x100
    ax25_release+0x2ad/0x360
    __sock_release+0x35/0xa0
    sock_close+0x19/0x20
    [...]

On reboot (or any attempt to remove the interface), the kernel gets
stuck in an infinite loop:

    unregister_netdevice: waiting for ax0 to become free. Usage count = 0

This patch corrects these issues by ensuring that we call netdev_hold()
and ax25_dev_hold() for new connections in ax25_accept(). This makes the
logic leading to ax25_accept() match the logic for ax25_bind(): in both
cases we increment the refcount, which is ultimately decremented in
ax25_release().

Fixes: 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()")
Signed-off-by: Lars Kellogg-Stedman <[email protected]>
Tested-by: Duoming Zhou <[email protected]>
Tested-by: Dan Cross <[email protected]>
Tested-by: Chris Maness <[email protected]>
Reviewed-by: Dan Carpenter <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoMerge branch 'virtio_net-fix-lock-warning-and-unrecoverable-state'
Jakub Kicinski [Sat, 1 Jun 2024 22:14:12 +0000 (15:14 -0700)]
Merge branch 'virtio_net-fix-lock-warning-and-unrecoverable-state'

Heng Qi says:

====================
virtio_net: fix lock warning and unrecoverable state

Patch 1 describes and fixes an issue where dim cannot return to
normal state in certain scenarios.

Patch 2 attempts to resolve lockdep's complaints that holding many
nested locks.
====================

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agovirtio_net: fix a spurious deadlock issue
Heng Qi [Tue, 28 May 2024 13:41:16 +0000 (21:41 +0800)]
virtio_net: fix a spurious deadlock issue

When the following snippet is run, lockdep will report a deadlock[1].

  /* Acquire all queues dim_locks */
  for (i = 0; i < vi->max_queue_pairs; i++)
          mutex_lock(&vi->rq[i].dim_lock);

There's no deadlock here because the vq locks are always taken
in the same order, but lockdep can not figure it out. So refactoring
the code to alleviate the problem.

[1]
========================================================
WARNING: possible recursive locking detected
6.9.0-rc7+ #319 Not tainted
--------------------------------------------
ethtool/962 is trying to acquire lock:

but task is already holding lock:

other info that might help us debug this:
Possible unsafe locking scenario:

      CPU0
      ----
 lock(&vi->rq[i].dim_lock);
 lock(&vi->rq[i].dim_lock);

*** DEADLOCK ***

 May be due to missing lock nesting notation

3 locks held by ethtool/962:
 #0: ffffffff82dbaab0 (cb_lock){++++}-{3:3}, at: genl_rcv+0x19/0x40
 #1: ffffffff82dad0a8 (rtnl_mutex){+.+.}-{3:3}, at:
ethnl_default_set_doit+0xbe/0x1e0

stack backtrace:
CPU: 6 PID: 962 Comm: ethtool Not tainted 6.9.0-rc7+ #319
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
   rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0x79/0xb0
 check_deadlock+0x130/0x220
 __lock_acquire+0x861/0x990
 lock_acquire.part.0+0x72/0x1d0
 ? lock_acquire+0xf8/0x130
 __mutex_lock+0x71/0xd50
 virtnet_set_coalesce+0x151/0x190
 __ethnl_set_coalesce.isra.0+0x3f8/0x4d0
 ethnl_set_coalesce+0x34/0x90
 ethnl_default_set_doit+0xdd/0x1e0
 genl_family_rcv_msg_doit+0xdc/0x130
 genl_family_rcv_msg+0x154/0x230
 ? __pfx_ethnl_default_set_doit+0x10/0x10
 genl_rcv_msg+0x4b/0xa0
 ? __pfx_genl_rcv_msg+0x10/0x10
 netlink_rcv_skb+0x5a/0x110
 genl_rcv+0x28/0x40
 netlink_unicast+0x1af/0x280
 netlink_sendmsg+0x20e/0x460
 __sys_sendto+0x1fe/0x210
 ? find_held_lock+0x2b/0x80
 ? do_user_addr_fault+0x3a2/0x8a0
 ? __lock_release+0x5e/0x160
 ? do_user_addr_fault+0x3a2/0x8a0
 ? lock_release+0x72/0x140
 ? do_user_addr_fault+0x3a7/0x8a0
 __x64_sys_sendto+0x29/0x30
 do_syscall_64+0x78/0x180
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Fixes: 4d4ac2ececd3 ("virtio_net: Add a lock for per queue RX coalesce")
Signed-off-by: Heng Qi <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Xuan Zhuo <[email protected]>
Acked-by: Jason Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agovirtio_net: fix possible dim status unrecoverable
Heng Qi [Tue, 28 May 2024 13:41:15 +0000 (21:41 +0800)]
virtio_net: fix possible dim status unrecoverable

When the dim worker is scheduled, if it no longer needs to issue
commands, dim may not be able to return to the working state later.

For example, the following single queue scenario:
  1. The dim worker of rxq0 is scheduled, and the dim status is
     changed to DIM_APPLY_NEW_PROFILE;
  2. dim is disabled or parameters have not been modified;
  3. virtnet_rx_dim_work exits directly;

Then, even if net_dim is invoked again, it cannot work because the
state is not restored to DIM_START_MEASURE.

Fixes: 6208799553a8 ("virtio-net: support rx netdim")
Signed-off-by: Heng Qi <[email protected]>
Reviewed-by: Jiri Pirko <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Reviewed-by: Xuan Zhuo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoethtool: init tsinfo stats if requested
Vadim Fedorenko [Thu, 30 May 2024 04:08:14 +0000 (21:08 -0700)]
ethtool: init tsinfo stats if requested

Statistic values should be set to ETHTOOL_STAT_NOT_SET even if the
device doesn't support statistics. Otherwise zeros will be returned as
if they are proper values:

host# ethtool -I -T lo
Time stamping parameters for lo:
Capabilities:
software-transmit
software-receive
software-system-clock
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes: none
Hardware Receive Filter Modes: none
Statistics:
  tx_pkts: 0
  tx_lost: 0
  tx_err: 0

Fixes: 0e9c127729be ("ethtool: add interface to read Tx hardware timestamping statistics")
Suggested-by: Jakub Kicinski <[email protected]>
Signed-off-by: Vadim Fedorenko <[email protected]>
Reviewed-by: Rahul Rameshbabu <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoMAINTAINERS: remove Peter Geis
Peter Geis [Wed, 29 May 2024 18:56:35 +0000 (14:56 -0400)]
MAINTAINERS: remove Peter Geis

The Motorcomm PHY driver is now maintained by the OEM. The driver has
expanded far beyond my original purpose, and I do not have the hardware
to test against the new portions of it. Therefore I am removing myself as
a maintainer of the driver.

Signed-off-by: Peter Geis <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agovirtio_net: fix missing lock protection on control_buf access
Heng Qi [Thu, 30 May 2024 03:41:43 +0000 (11:41 +0800)]
virtio_net: fix missing lock protection on control_buf access

Refactored the handling of control_buf to be within the cvq_lock
critical section, mitigating race conditions between reading device
responses and new command submissions.

Fixes: 6f45ab3e0409 ("virtio_net: Add a lock for the command VQ.")
Signed-off-by: Heng Qi <[email protected]>
Reviewed-by: Hariprasad Kelam <[email protected]>
Acked-by: Jason Wang <[email protected]>
Reviewed-by: Xuan Zhuo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
9 months agoMerge tag '6.10-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6
Linus Torvalds [Sat, 1 Jun 2024 21:35:57 +0000 (14:35 -0700)]
Merge tag '6.10-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6

Pull smb client fixes from Steve French:
 "Two small smb3 fixes:

   - Fix socket creation with sfu mount option (spotted by test generic/423)

   - Minor cleanup: fix missing description in two files"

* tag '6.10-rc1-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: fix creating sockets when using sfu mount options
  fs: smb: common: add missing MODULE_DESCRIPTION() macros

9 months agoio_uring: check for non-NULL file pointer in io_file_can_poll()
Jens Axboe [Sat, 1 Jun 2024 18:25:35 +0000 (12:25 -0600)]
io_uring: check for non-NULL file pointer in io_file_can_poll()

In earlier kernels, it was possible to trigger a NULL pointer
dereference off the forced async preparation path, if no file had
been assigned. The trace leading to that looks as follows:

BUG: kernel NULL pointer dereference, address: 00000000000000b0
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022
RIP: 0010:io_buffer_select+0xc3/0x210
Code: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b
RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246
RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040
RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700
RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020
R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8
R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000
FS:  00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0
Call Trace:
 <TASK>
 ? __die+0x1f/0x60
 ? page_fault_oops+0x14d/0x420
 ? do_user_addr_fault+0x61/0x6a0
 ? exc_page_fault+0x6c/0x150
 ? asm_exc_page_fault+0x22/0x30
 ? io_buffer_select+0xc3/0x210
 __io_import_iovec+0xb5/0x120
 io_readv_prep_async+0x36/0x70
 io_queue_sqe_fallback+0x20/0x260
 io_submit_sqes+0x314/0x630
 __do_sys_io_uring_enter+0x339/0xbc0
 ? __do_sys_io_uring_register+0x11b/0xc50
 ? vm_mmap_pgoff+0xce/0x160
 do_syscall_64+0x5f/0x180
 entry_SYSCALL_64_after_hwframe+0x46/0x4e
RIP: 0033:0x55e0a110a67e
Code: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6

because the request is marked forced ASYNC and has a bad file fd, and
hence takes the forced async prep path.

Current kernels with the request async prep cleaned up can no longer hit
this issue, but for ease of backporting, let's add this safety check in
here too as it really doesn't hurt. For both cases, this will inevitably
end with a CQE posted with -EBADF.

Cc: [email protected]
Fixes: a76c0b31eef5 ("io_uring: commit non-pollable provided mapped buffers upfront")
Signed-off-by: Jens Axboe <[email protected]>
9 months agoMerge tag 'kbuild-fixes-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/masah...
Linus Torvalds [Sat, 1 Jun 2024 16:33:55 +0000 (09:33 -0700)]
Merge tag 'kbuild-fixes-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild fixes from Masahiro Yamada:

 - Fix a Kconfig bug regarding comparisons to 'm' or 'n'

 - Replace missed $(srctree)/$(src)

 - Fix unneeded kallsyms step 3

 - Remove incorrect "compatible" properties from image nodes in
   image.fit

 - Improve gen_kheaders.sh

 - Fix 'make dt_binding_check'

 - Clean up unnecessary code

* tag 'kbuild-fixes-v6.10' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  dt-bindings: kbuild: Fix dt_binding_check on unconfigured build
  kheaders: use `command -v` to test for existence of `cpio`
  kheaders: explicitly define file modes for archived headers
  scripts/make_fit: Drop fdt image entry compatible string
  kbuild: remove a stale comment about cleaning in link-vmlinux.sh
  kbuild: fix short log for AS in link-vmlinux.sh
  kbuild: change scripts/mksysmap into sed script
  kbuild: avoid unneeded kallsyms step 3
  kbuild: scripts/gdb: Replace missed $(srctree)/$(src) w/ $(src)
  kconfig: remove redundant check in expr_join_or()
  kconfig: fix comparison to constant symbols, 'm', 'n'
  kconfig: remove unused expr_is_no()

This page took 0.133359 seconds and 4 git commands to generate.