24.04: Linux 6.11.3 #339
Open
24.04: Linux 6.11.3 #339
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[ Upstream commit 5cc69a2 ] We need to migrate data blocks even though it is full to secure space for zoned device file pinning. Fixes: 9703d69 ("f2fs: support file pinning for zoned devices") Signed-off-by: Daeho Jeong <[email protected]> Reviewed-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
commit 3f7f36a upstream. This reverts commit 478689b. The fix seems leading to regressions for other systems. Also, the way to check the presence of IOMMU via get_dma_ops() isn't reliable and it's no longer applicable for 6.12. After all, it's no right fix, so let's revert it at first. To be noted, the PCM buffer allocation has been changed to try the continuous pages at first since 6.12, so the problem could be already addressed without this hackish workaround. Reported-by: Salvatore Bonaccorso <[email protected]> Closes: https://lore.kernel.org/[email protected] Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…ice_register() errors commit 2fae312 upstream. x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed. Fixes: 5eba014 ("platform/x86: x86-android-tablets: Add support for instantiating platform-devs") Fixes: e2200d3 ("platform/x86: x86-android-tablets: Add gpio_keys support to x86_android_tablet_init()") Cc: [email protected] Reported-by: Aleksandr Burakov <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/ Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 7d59ac0 upstream. Attaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] <TASK> [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] </TASK> [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: kasan: bad access detected [ 19.505058] [ 19.505970] Memory state around the buggy address: [ 19.507172] ffff888829e65100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 19.508599] ffff888829e65180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 19.510013] >ffff888829e65200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 19.510014] ^ [ 19.510016] ffff888829e65280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 19.510018] ffff888829e65300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 19.515367] ================================================================== The reason for this error is physical_package_ids assigned by VMware VMM are not continuous and have gaps. This will cause value returned by topology_physical_package_id() to be more than topology_max_packages(). Here the allocation uses topology_max_packages(). The call to topology_max_packages() returns maximum logical package ID not physical ID. Hence use topology_logical_package_id() instead of topology_physical_package_id(). Fixes: 9a1aac8 ("platform/x86: ISST: PUNIT device mapping with Sub-NUMA clustering") Cc: [email protected] Acked-by: Srinivas Pandruvada <[email protected]> Signed-off-by: Zach Wade <[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]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit a1d402a upstream. Oliver reports that the kvm_has_feat() helper is not behaviing as expected for negative feature. On investigation, the main issue seems to be caused by the following construct: #define get_idreg_field(kvm, id, fld) \ (id##_##fld##_SIGNED ? \ get_idreg_field_signed(kvm, id, fld) : \ get_idreg_field_unsigned(kvm, id, fld)) where one side of the expression evaluates as something signed, and the other as something unsigned. In retrospect, this is totally braindead, as the compiler converts this into an unsigned expression. When compared to something that is 0, the test is simply elided. Epic fail. Similar issue exists in the expand_field_sign() macro. The correct way to handle this is to chose between signed and unsigned comparisons, so that both sides of the ternary expression are of the same type (bool). In order to keep the code readable (sort of), we introduce new comparison primitives taking an operator as a parameter, and rewrite the kvm_has_feat*() helpers in terms of these primitives. Fixes: c62d7a2 ("KVM: arm64: Add feature checking helpers") Reported-by: Oliver Upton <[email protected]> Tested-by: Oliver Upton <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…esume commit 048bbbd upstream. In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex. Acked-by: Alain Volmat <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Fixes: 4e7bca6 ("i2c: i2c-stm32f7: add PM Runtime support") Cc: <[email protected]> # v5.0+ Signed-off-by: Andi Shyti <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e2c85d8 upstream. disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 37692de ("i2c: i2c-qcom-geni: Add bus driver for the Qualcomm GENI I2C controller") Signed-off-by: Jinjie Ruan <[email protected]> Cc: <[email protected]> # v4.19+ Acked-by: Mukesh Kumar Savaliya <[email protected]> Reviewed-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 521da1e upstream. Frequently an I2C write will be followed by a read, such as a register address write followed by a read of the register value. In this driver, when the TX FIFO half empty interrupt was raised and it was determined that there was enough space in the TX FIFO to send the following read command, it would do so without waiting for the TX FIFO to actually empty. Unfortunately it appears that in some cases this can result in a NAK that was raised by the target device on the write, such as due to an unsupported register address, being ignored and the subsequent read being done anyway. This can potentially put the I2C bus into an invalid state and/or result in invalid read data being processed. To avoid this, once a message has been fully written to the TX FIFO, wait for the TX FIFO empty interrupt before moving on to the next message, to ensure NAKs are handled properly. Fixes: e1d5b65 ("i2c: Add support for Xilinx XPS IIC Bus Interface") Signed-off-by: Robert Hancock <[email protected]> Cc: <[email protected]> # v2.6.34+ Reviewed-by: Manikanta Guntupalli <[email protected]> Acked-by: Michal Simek <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit bee1aed upstream. If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ... Signed-off-by: Alexander Shiyan <[email protected]> Fixes: 852b50a ("media: On Semi AR0521 sensor driver") Cc: [email protected] Acked-by: Krzysztof Hałasa <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 8d3cefa upstream. Krzysztof reported an issue [0] which is caused by parallel attempts to instantiate the same I2C client device. This can happen if driver supports auto-detection, but certain devices are also instantiated explicitly. The original change isn't actually wrong, it just revealed that I2C core isn't prepared yet to handle this scenario. Calls to i2c_new_client_device() can be nested, therefore we can't use a simple mutex here. Parallel instantiation of devices at different addresses is ok, so we just have to prevent parallel instantiation at the same address. We can use a bitmap with one bit per 7-bit I2C client address, and atomic bit operations to set/check/clear bits. Now a parallel attempt to instantiate a device at the same address will result in -EBUSY being returned, avoiding the "sysfs: cannot create duplicate filename" splash. Note: This patch version includes small cosmetic changes to the Tested-by version, only functional change is that address locking is supported for slave addresses too. [0] https://lore.kernel.org/linux-i2c/[email protected]/T/#m12706546e8e2414d8f1a0dc61c53393f731685cc Fixes: caba40e ("eeprom: at24: Probe for DDR3 thermal sensor in the SPD case") Cc: [email protected] Tested-by: Krzysztof Piotr Oledzki <[email protected]> Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 0c8d604 upstream. It is not valid to call pm_runtime_set_suspended() for devices with runtime PM enabled because it returns -EAGAIN if it is enabled already and working. So, call pm_runtime_disable() before to fix it. Fixes: 36ecbca ("i2c: xiic: Implement power management") Cc: <[email protected]> # v4.6+ Signed-off-by: Jinjie Ruan <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…s disabled commit 5d69d5a upstream. It was observed that issuing the ABORT bit (IC_ENABLE[1]) will not work when IC_ENABLE is already disabled. Check if the ENABLE bit (IC_ENABLE[0]) is disabled when the controller is holding SCL low. If the ENABLE bit is disabled, the software needs to enable it before trying to issue the ABORT bit. otherwise, the controller ignores any write to ABORT bit. These kernel logs show up whenever an I2C transaction is attempted after this failure. i2c_designware e95e0000.i2c: timeout waiting for bus ready i2c_designware e95e0000.i2c: timeout in disabling adapter The patch fixes the issue where the controller cannot be disabled while SCL is held low if the ENABLE bit is already disabled. Fixes: 2409205 ("i2c: designware: fix __i2c_dw_disable() in case master is holding SCL low") Signed-off-by: Kimriver Liu <[email protected]> Cc: <[email protected]> # v6.6+ Reviewed-by: Mika Westerberg <[email protected]> Acked-by: Jarkko Nikula <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f2990f8 upstream. ACPI boot does not provide clocks and regulators, but instead, provides the PCLK rate directly, and enables the clock in firmware. So deal gracefully with this. Fixes: 5575014 ("i2c: synquacer: Fix an error handling path in synquacer_i2c_probe()") Cc: [email protected] # v6.10+ Cc: Andi Shyti <[email protected]> Cc: Christophe JAILLET <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit a8ee30f upstream. The `LockedBy::access` method only requires a shared reference to the owner, so if we have shared access to the `LockedBy` from several threads at once, then two threads could call `access` in parallel and both obtain a shared reference to the inner value. Thus, require that `T: Sync` when calling the `access` method. An alternative is to require `T: Sync` in the `impl Sync for LockedBy`. This patch does not choose that approach as it gives up the ability to use `LockedBy` with `!Sync` types, which is okay as long as you only use `access_mut`. Cc: [email protected] Fixes: 7b1f55e ("rust: sync: introduce `LockedBy`") Signed-off-by: Alice Ryhl <[email protected]> Suggested-by: Boqun Feng <[email protected]> Reviewed-by: Gary Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Miguel Ojeda <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 6c4a5f9 upstream. Some overlayfs features require permission to read/write trusted.* xattrs. These include redirect_dir, verity, metacopy, and data-only layers. This patch adds additional validations at mount time to stop overlays from mounting in certain cases where the resulting mount would not function according to the user's expectations because they lack permission to access trusted.* xattrs (for example, not global root.) Similar checks in ovl_make_workdir() that disable features instead of failing are still relevant and used in cases where the resulting mount can still work "reasonably well." Generally, if the feature was enabled through kernel config or module option, any mount that worked before will still work the same; this applies to redirect_dir and metacopy. The user must explicitly request these features in order to generate a mount failure. Verity and data-only layers on the other hand must be explictly requested and have no "reasonable" disabled or degraded alternative, so mounts attempting either always fail. "lower data-only dirs require metacopy support" moved down in case userxattr is set, which disables metacopy. Cc: [email protected] # v6.6+ Signed-off-by: Mike Baynton <[email protected]> Signed-off-by: Amir Goldstein <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 9c3a62c upstream. mbox_client_to_bpmp() is not used, W=1 builds: drivers/firmware/tegra/bpmp.c:28:1: error: unused function 'mbox_client_to_bpmp' [-Werror,-Wunused-function] Fixes: cdfa358 ("firmware: tegra: Refactor BPMP driver") Cc: [email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 67dd9e8 upstream. to_tegra186_emc() is not used, W=1 builds: tegra186-emc.c:38:36: error: unused function 'to_tegra186_emc' [-Werror,-Wunused-function] Fixes: 9a38cb2 ("memory: tegra: Add interconnect support for DRAM scaling in Tegra234") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit abf3a3e upstream. The numbering in Exynos7885's FSYS CMU bindings has 4 duplicated by accident, with the rest of the bindings continuing with 5. Fix this by moving CLK_MOUT_FSYS_USB30DRD_USER to the end as 11. Since CLK_MOUT_FSYS_USB30DRD_USER is not used in any device tree as of now, and there are no other clocks affected (maybe apart from CLK_MOUT_FSYS_MMC_SDIO_USER which the number was shared with, also not used in a device tree), this is the least impactful way to solve this problem. Fixes: cd268e3 ("dt-bindings: clock: Add bindings for Exynos7885 CMU_FSYS") Cc: [email protected] Signed-off-by: David Virag <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 909f34f upstream. Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from platform_device_id table. Fixes: 44d8fb3 ("spi/bcm63xx: move register definitions into the driver") Cc: [email protected] Signed-off-by: Jinjie Ruan <[email protected]> Reviewed-by: Jonas Gorski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 2656972 upstream. The pm_runtime_disable() is missing in the remove function, fix it by using devm_pm_runtime_enable(), so the pm_runtime_disable() in the probe error path can also be removed. Fixes: 2d13f2f ("spi: bcm63xx-spi: fix pm_runtime") Cc: [email protected] # v5.13+ Signed-off-by: Jinjie Ruan <[email protected]> Suggested-by: Jonas Gorski <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit e50a57d upstream. Temp channel 0 aka temp1 can have a temp1_max_alarm attribute for power_supply devices which have a POWER_SUPPLY_PROP_TEMP_ALERT_MAX property. HWMON_T_MAX_ALARM was missing from power_supply_hwmon_info for temp channel 0, causing the hwmon temp1_max_alarm attribute to be missing from such power_supply devices. Add this to power_supply_hwmon_info to fix this. Fixes: f1d33ae ("power: supply: remove duplicated argument in power_supply_hwmon_info") Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 59090e4 upstream. Since commit 946fa0d ("mm/slub: extend redzone check to extra allocated kmalloc space than requested"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with "slub_debug=FUZ init_on_free=1": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size. Fixes: 946fa0d ("mm/slub: extend redzone check to extra allocated kmalloc space than requested") Cc: <[email protected]> Reviewed-by: Feng Tang <[email protected]> Acked-by: David Rientjes <[email protected]> Signed-off-by: Peng Fan <[email protected]> Signed-off-by: Vlastimil Babka <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…able() commit 78f281e upstream. power_supply_property_is_writeable() gets called from the is_visible() callback for the sysfs attributes of power_supply class devices and for the sysfs attributes of power_supply core instantiated hwmon class devices. These sysfs attributes get registered by the device_add() respectively power_supply_add_hwmon_sysfs() calls in power_supply_register(). use_cnt gets initialized to 0 and is incremented only after these calls. So when power_supply_property_is_writeable() gets called it always return -ENODEV because of use_cnt == 0. This causes all the attributes to have permissions of 444 even those which should be writable. This used to be a problem only for hwmon sysfs attributes but since commit be6299c ("power: supply: sysfs: use power_supply_property_is_writeable()") this now also impacts power_supply class sysfs attributes. Fixes: be6299c ("power: supply: sysfs: use power_supply_property_is_writeable()") Fixes: e67d4df ("power: supply: Add HWMON compatibility layer") Cc: [email protected] Cc: Thomas Weißschuh <[email protected]> Cc: Andrey Smirnov <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/stable/20240908185337.103696-1-hdegoede%40redhat.com Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sebastian Reichel <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 62c0b10 upstream. In perf_adjust_period, we will first calculate period, and then use this period to calculate delta. However, when delta is less than 0, there will be a deviation compared to when delta is greater than or equal to 0. For example, when delta is in the range of [-14,-1], the range of delta = delta + 7 is between [-7,6], so the final value of delta/8 is 0. Therefore, the impact of -1 and -2 will be ignored. This is unacceptable when the target period is very short, because we will lose a lot of samples. Here are some tests and analyzes: before: # perf record -e cs -F 1000 ./a.out [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.022 MB perf.data (518 samples) ] # perf script ... a.out 396 257.956048: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.957891: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.959730: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.961545: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.963355: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.965163: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.966973: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.968785: 23 cs: ffffffff81f4eeec schedul> a.out 396 257.970593: 23 cs: ffffffff81f4eeec schedul> ... after: # perf record -e cs -F 1000 ./a.out [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.058 MB perf.data (1466 samples) ] # perf script ... a.out 395 59.338813: 11 cs: ffffffff81f4eeec schedul> a.out 395 59.339707: 12 cs: ffffffff81f4eeec schedul> a.out 395 59.340682: 13 cs: ffffffff81f4eeec schedul> a.out 395 59.341751: 13 cs: ffffffff81f4eeec schedul> a.out 395 59.342799: 12 cs: ffffffff81f4eeec schedul> a.out 395 59.343765: 11 cs: ffffffff81f4eeec schedul> a.out 395 59.344651: 11 cs: ffffffff81f4eeec schedul> a.out 395 59.345539: 12 cs: ffffffff81f4eeec schedul> a.out 395 59.346502: 13 cs: ffffffff81f4eeec schedul> ... test.c int main() { for (int i = 0; i < 20000; i++) usleep(10); return 0; } # time ./a.out real 0m1.583s user 0m0.040s sys 0m0.298s The above results were tested on x86-64 qemu with KVM enabled using test.c as test program. Ideally, we should have around 1500 samples, but the previous algorithm had only about 500, whereas the modified algorithm now has about 1400. Further more, the new version shows 1 sample per 0.001s, while the previous one is 1 sample per 0.002s.This indicates that the new algorithm is more sensitive to small negative values compared to old algorithm. Fixes: bd2b5b1 ("perf_counter: More aggressive frequency adjustment") Signed-off-by: Luo Gengkun <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Reviewed-by: Adrian Hunter <[email protected]> Reviewed-by: Kan Liang <[email protected]> Cc: [email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f32b512 upstream. Check that the number of perfmons userspace is passing in the copy and reset extensions is not greater than the internal kernel storage where the ids will be copied into. Signed-off-by: Tvrtko Ursulin <[email protected]> Fixes: bae7cb5 ("drm/v3d: Create a CPU job extension for the reset performance query job") Cc: Maíra Canal <[email protected]> Cc: Iago Toral Quiroga <[email protected]> Cc: [email protected] # v6.8+ Reviewed-by: Iago Toral Quiroga <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 9542130 upstream. For an itlb miss when executing code above 4 Gb on ILP64 adjust the iasq/iaoq in the same way isr/ior was adjusted. This fixes signal delivery for the 64-bit static test program from http://ftp.parisc-linux.org/src/64bit.tar.gz. Note that signals are handled by the signal trampoline code in the 64-bit VDSO which is mapped into high userspace memory region above 4GB for 64-bit processes. Signed-off-by: Helge Deller <[email protected]> Cc: [email protected] # v4.19+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 5beb6fb upstream. Error paths that exit for_each_child_of_node() need to call of_node_put() to decerement the child refcount and avoid memory leaks. Add the missing of_node_put(). Cc: [email protected] Fixes: 453c336 ("drm/mediatek: Add ovl_adaptor support for MT8195") Signed-off-by: Javier Carrasco <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 8b0d2f6 upstream. FB_DAMAGE_CLIPS is a plane property for damage handling. Its UAPI should only use UAPI types. Hence replace struct drm_rect with struct drm_mode_rect in drm_atomic_plane_set_property(). Both types are identical in practice, so there's no change in behavior. Reported-by: Ville Syrjälä <[email protected]> Closes: https://lore.kernel.org/dri-devel/[email protected]/ Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: d3b2176 ("drm: Add a new plane property to send damage during plane update") Cc: Lukasz Spintzyk <[email protected]> Cc: Deepak Rawat <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Thomas Hellstrom <[email protected]> Cc: David Airlie <[email protected]> Cc: Simona Vetter <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: [email protected] Cc: <[email protected]> # v5.0+ Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 49f5ee9 upstream. Add new vendor_id and subsystem_id in quirk for Lenovo Y990 Laptop. Signed-off-by: Baojun Xu <[email protected]> Cc: <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit d278a9d upstream. The card identifier should contain only safe ASCII characters. The isalnum() returns true also for characters for non-ASCII characters. Link: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4135 Link: https://lore.kernel.org/linux-sound/yk3WTvKkwheOon_LzZlJ43PPInz6byYfBzpKkbasww1yzuiMRqn7n6Y8vZcXB-xwFCu_vb8hoNjv7DTNwH5TWjpEuiVsyn9HPCEXqwF4120=@protonmail.com/ Cc: [email protected] Reported-by: Barnabás Pőcze <[email protected]> Signed-off-by: Jaroslav Kysela <[email protected]> Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Asus released motherboard(s) with an alternate ALC4080 that lacks a SPDIF jack, and requires applying this map.
The Aorus Xtreme uses the same ID for audio controller, but the maps are very different. This successfully fixes all of the audio jacks on the back.
When plugging of unplugging an audio jack on this motherbaord, sometimes the audio jacks would stop appearing to pipewire/pulseaudio. Interestingly `cat`-ing out the file `/proc/asound/<card number>/codec#0`, and or restarting pipewire fixes the issue temporarily. This PR improves the current functionality by making hotplug with one 3.5mm jack work, it still breaks if hotplug is between multiple jacks though.
This reverts commit 86f4c65.
This reverts commit b38f2d5.
This reverts commit 81f6650.
Signed-off-by: Tim Crawford <[email protected]>
This reverts commit 112a7f9.
This reverts commit 0470d83. Barlow Ridge removes support for FWCM. Signed-off-by: Tim Crawford <[email protected]>
The Nvidia proprietary driver has some bugs that leads to issues if used with the simpledrm driver. The most noticeable is that does not register an emulated fbdev device. It just relies on a fbdev to be registered by another driver, that could be that could be attached to the framebuffer console. On UEFI machines, this is the efifb driver. This means that disabling the efifb driver will cause virtual consoles to not be present in the system when using the Nvidia driver. Legacy BIOS is not affected just because fbcon is not used there, but instead vgacon. Unless a VGA mode is specified using the vga= kernel command line option, in that case the vesafb driver is used instead and its fbdev attached to the fbcon. This is a problem because with CONFIG_SYSFB_SIMPLEFB=y, the sysfb platform code attempts to register a "simple-framebuffer" platform device (that is matched against simpledrm) and only registers either an "efi-framebuffer" or "vesa-framebuffer" if this fails to be registered due the video modes not being compatible. The Nvidia driver relying on another driver to register the fbdev is quite fragile, since it can't really assume those will stick around. For example there are patches posted to remove the EFI and VESA platform devices once a real DRM or fbdev driver probes. But in any case, moving to a simpledrm + emulated fbdev only breaks this assumption and causes users to not have VT if the Nvidia driver is used. So to prevent this, let's add a workaround and make the sysfb to skip the "simple-framebuffer" registration when nvidia-drm.modeset=1 option is set. This is quite horrible, but honestly I can't think of any other approach. For this to work, the CONFIG_FB_EFI and CONFIG_FB_VESA config options must be enabled besides CONFIG_DRM_SIMPLEDRM. Signed-off-by: Javier Martinez Canillas <[email protected]>
…02409151536 Signed-off-by: Michael Aaron Murphy <[email protected]>
|
This causes freezes on Framework AMD for me (edit: apparently not only me): |
|
Is there a way to get this kernel early? Or even try a 6.12-rc kernel? I just got a lunar lake laptop and stuff like wifi/sound doesn't work rn, so I'm hoping for a quick way to get the latest kernel. |
As a fellow pop user, you can do Obviously, since the pop team is still in the process of testing this and it hasn't been merged yet you may experience issues. |
|
Oh hell yeah, I had no idea https://apt-origin.pop-os.org/staging/ was a big list of packages you could add. Anyway the command is Edit: well it's running 6.11 just fine but apparently lunar lake won't be usable until 6.12 https://www.reddit.com/r/linux/comments/1fq908x/fedora_41_beta_running_on_asus_zenbook_s_14/ |
Due to the bluetooth audio breakage mentioned in pop-os/pop#3347, I tried to update to 6.11.3 using this method, but was met with: So I guess the nvidia modules are borked for now, even had to use the refresh install option to recover from this. (Props to the PopOS team for even having this rather user-friendly way to recover even with an encrypted drive!) |
|
@mmstick this patch fixed my issue on Framework AMD. |
|
guys are u aware about this? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.