- Dec 05, 2024
-
-
Krzysztof Kozlowski authored
commit ffb30875172eabff727e2896f097ccd4bb68723f upstream. Commit 904140fa ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers") added samsung,exynos7-wakeup-eint fallback to some compatibles, so the intention in the if:then: conditions was to handle the cases: 1. Single Exynos7 compatible or Exynos5433+Exynos7 or Exynos7885+Exynos7: only one interrupt 2. Exynos850+Exynos7: no interrupts This was not implemented properly however and if:then: block matches only single Exynos5433 or Exynos7885 compatibles, which do not exist in DTS anymore, so basically is a no-op and no enforcement on number of interrupts is made by the binding. Fix the if:then: condition so interrupts in the Exynos5433 and Exynos7885 wake-up pin controller will be properly constrained. Fixes: 904140fa ("dt-bindings: pinctrl: samsung: use Exynos7 fallbacks for newer wake-up controllers") Cc: stable@vger.kernel.org Acked-by:
Rob Herring (Arm) <robh@kernel.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20241015065848.29429-1-krzysztof.kozlowski@linaro.org Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Johan Hovold authored
commit 6bc0ebfb1d920f13c522545f114cdabb49e9408a upstream. Commit 723e8462 ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping") fixed a long-standing issue in the Qualcomm SPMI PMIC gpio driver which had the 'low' and 'high' drive strength settings switched but failed to update the debugfs interface which still gets this wrong. Fix the debugfs code so that the exported values match the hardware settings. Note that this probably means that most devicetrees that try to describe the firmware settings got this wrong if the settings were derived from debugfs. Before the above mentioned commit the settings would have actually matched the firmware settings even if they were described incorrectly, but now they are inverted. Fixes: 723e8462 ("pinctrl: qcom: spmi-gpio: Fix the GPIO strength mapping") Fixes: eadff302 ("pinctrl: Qualcomm SPMI PMIC GPIO pin controller driver") Cc: Anjelique Melendez <quic_amelende@quicinc.com> Cc: stable@vger.kernel.org # 3.19 Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Reviewed-by:
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/20241025121622.1496-1-johan+linaro@kernel.org Signed-off-by:
-
Christian Brauner authored
commit 2714b0d1f36999dbd99a3474a24e7301acbd74f1 upstream. Currently when passing a closed file descriptor to fcntl(fd, F_DUPFD_QUERY, fd_dup) the order matters: fd = open("/dev/null"); fd_dup = dup(fd); When we now close one of the file descriptors we get: (1) fcntl(fd, fd_dup) // -EBADF (2) fcntl(fd_dup, fd) // 0 aka not equal depending on which file descriptor is passed first. That's not a huge deal but it gives the api I slightly weird feel. Make it so that the order doesn't matter by requiring that both file descriptors are valid: (1') fcntl(fd, fd_dup) // -EBADF (2') fcntl(fd_dup, fd) // -EBADF Link: https://lore.kernel.org/r/20241008-duften-formel-251f967602d5@brauner Fixes: c62b758b ("fcntl: add F_DUPFD_QUERY fcntl()") Reviewed-by:Jeff Layton <jlayton@kernel.org> Reviewed-By:
Lennart Poettering <lennart@poettering.net> Cc: stable@vger.kernel.org Reported-by:
Christian Brauner <brauner@kernel.org> Signed-off-by:
-
Thomas Weißschuh authored
commit 711b5875814b2a0e9a5aaf7a85ba7c80f5a389b1 upstream. arch-s390.h uses types from std.h, but does not include it. Depending on the inclusion order the compilation can fail. Include std.h explicitly to avoid these errors. Fixes: 404fa87c ("tools/nolibc: s390: provide custom implementation for sys_fork") Cc: stable@vger.kernel.org Signed-off-by:
Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://lore.kernel.org/r/20240927-nolibc-s390-std-h-v1-1-30442339a6b9@linutronix.de Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Signed-off-by:
-
Ahmed Ehab authored
commit d7fe143cb115076fed0126ad8cf5ba6c3e575e43 upstream. Syzbot reports a problem that a warning will be triggered while searching a lock class in look_up_lock_class(). The cause of the issue is that a new name is created and used by lockdep_set_subclass() instead of using the existing one. This results in a lock instance has a different name pointer than previous registered one stored in lock class, and WARN_ONCE() is triggered because of that in look_up_lock_class(). To fix this, change lockdep_set_subclass() to use the existing name instead of a new one. Hence, no new name will be created by lockdep_set_subclass(). Hence, the warning is avoided. [boqun: Reword the commit log to state the correct issue] Reported-by:
<syzbot+7f4a6f7f7051474e40ad@syzkaller.appspotmail.com> Fixes: de8f5e4f ("lockdep: Introduce wait-type checks") Cc: stable@vger.kernel.org Signed-off-by:
Ahmed Ehab <bottaawesome633@gmail.com> Signed-off-by:
Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/lkml/20240824221031.7751-1-bottaawesome633@gmail.com/ Signed-off-by:
-
Nicolas Bouchinet authored
commit 635a9fca54f4f4148be1ae1c7c6bd37af80f5773 upstream. Commit 7c0cca7c ("tty: ldisc: add sysctl to prevent autoloading of ldiscs") introduces the tty_ldisc_autoload sysctl with the wrong proc_handler. .extra1 and .extra2 parameters are set to avoid other values thant SYSCTL_ZERO or SYSCTL_ONE to be set but proc_dointvec do not uses them. This commit fixes this by using proc_dointvec_minmax instead of proc_dointvec. Fixes: 7c0cca7c ("tty: ldisc: add sysctl to prevent autoloading of ldiscs") Cc: stable <stable@kernel.org> Signed-off-by:
Nicolas Bouchinet <nicolas.bouchinet@ssi.gouv.fr> Reviewed-by:
Lin Feng <linf@wangsu.com> Reviewed-by:
Jiri Slaby <jirislaby@kernel.org> Link: https://lore.kernel.org/r/20241112131357.49582-4-nicolas.bouchinet@clip-os.org Signed-off-by:
-
Angelo Dureghello authored
commit 70602f529e4d76798c95aeed5ce2a8d36263abe5 upstream. Fix ADI_DAC_R1_MODE of AXI_DAC_REG_CNTRL_2. Both generic DAC and ad3552r DAC IPs docs are reporting bit 5 for it. Link: https://wiki.analog.com/resources/fpga/docs/axi_dac_ip Fixes: 4e3949a1 ("iio: dac: add support for AXI DAC IP core") Cc: stable@vger.kernel.org Signed-off-by:
Angelo Dureghello <adureghello@baylibre.com> Reviewed-by:
Nuno Sa <nuno.sa@analog.com> Link: https://patch.msgid.link/20241008-wip-bl-ad3552r-axi-v0-iio-testing-v5-1-3d410944a63d@baylibre.com Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Jinjie Ruan authored
commit 7290f59231910ccba427d441a6e8b8c6f6112448 upstream. The string allocated by kmemdup() in aa_unpack_strdup() is not freed and cause following memory leaks, free them to fix it. unreferenced object 0xffffff80c6af8a50 (size 8): comm "kunit_try_catch", pid 225, jiffies 4294894407 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0 [<000000006870467c>] kmemdup_noprof+0x34/0x60 [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c [<000000008ecde918>] policy_unpack_test_unpack_strdup_with_null_name+0xf8/0x3ec [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20 unreferenced object 0xffffff80c2a29090 (size 8): comm "kunit_try_catch", pid 227, jiffies 4294894409 hex dump (first 8 bytes): 74 65 73 74 69 6e 67 00 testing. backtrace (crc 5eab668b): [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 [<000000006e6c7776>] __kmalloc_node_track_caller_noprof+0x300/0x3e0 [<000000006870467c>] kmemdup_noprof+0x34/0x60 [<000000001176bb03>] aa_unpack_strdup+0xd0/0x18c [<0000000046a45c1a>] policy_unpack_test_unpack_strdup_with_name+0xd0/0x3c4 [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000adf936cf>] kthread+0x2e8/0x374 [<0000000041bb1628>] ret_from_fork+0x10/0x20 Cc: stable@vger.kernel.org Fixes: 4d944bcd ("apparmor: add AppArmor KUnit tests for policy unpack") Signed-off-by:
Jinjie Ruan <ruanjinjie@huawei.com> Signed-off-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
Jann Horn authored
commit ce8f9fb651fac95dd41f69afe54d935420b945bd upstream. If some remap_pfn_range() calls succeeded before one failed, we still have buffer pages mapped into the userspace page tables when we drop the buffer reference with comedi_buf_map_put(bm). The userspace mappings are only cleaned up later in the mmap error path. Fix it by explicitly flushing all mappings in our VMA on the error path. See commit 79a61cc3 ("mm: avoid leaving partial pfn mappings around in error case"). Cc: stable@vger.kernel.org Fixes: ed9eccbe ("Staging: add comedi core") Signed-off-by:
Jann Horn <jannh@google.com> Link: https://lore.kernel.org/r/20241017-comedi-tlb-v3-1-16b82f9372ce@google.com Signed-off-by:
-
Jann Horn authored
commit 21d1b618b6b9da46c5116c640ac4b1cc8d40d63a upstream. Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info. Cc: stable@kernel.org Fixes: d2f277e2 ("fsnotify: rename fsnotify_{get,put}_sb_connectors()") Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Amir Goldstein authored
commit aa52c54da40d9eee3ba87c05cdcb0cd07c04fa13 upstream. We got a report that adding a fanotify filsystem watch prevents tail -f from receiving events. Reproducer: 1. Create 3 windows / login sessions. Become root in each session. 2. Choose a mounted filesystem that is pretty quiet; I picked /boot. 3. In the first window, run: fsnotifywait -S -m /boot 4. In the second window, run: echo data >> /boot/foo 5. In the third window, run: tail -f /boot/foo 6. Go back to the second window and run: echo more data >> /boot/foo 7. Observe that the tail command doesn't show the new data. 8. In the first window, hit control-C to interrupt fsnotifywait. 9. In the second window, run: echo still more data >> /boot/foo 10. Observe that the tail command in the third window has now printed the missing data. When stracing tail, we observed that when fanotify filesystem mark is set, tail does get the inotify event, but the event is receieved with the filename: read(4, "\1\0\0\0\2\0\0\0\0\0\0\0\20\0\0\0foo\0\0\0\0\0\0\0\0\0\0\0\0\0", 50) = 32 This is unexpected, because tail is watching the file itself and not its parent and is inconsistent with the inotify event received by tail when fanotify filesystem mark is not set: read(4, "\1\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0", 50) = 16 The inteference between different fsnotify groups was caused by the fact that the mark on the sb requires the filename, so the filename is passed to fsnotify(). Later on, fsnotify_handle_event() tries to take care of not passing the filename to groups (such as inotify) that are interested in the filename only when the parent is watching. But the logic was incorrect for the case that no group is watching the parent, some groups are watching the sb and some watching the inode. Reported-by:
Miklos Szeredi <miklos@szeredi.hu> Fixes: 7372e79c ("fanotify: fix logic of reporting name info with watched parent") Cc: stable@vger.kernel.org # 5.10+ Signed-off-by:
Amir Goldstein <amir73il@gmail.com> Signed-off-by:
-
Gustavo A. R. Silva authored
commit 02fb4f0084331ef72c28d0c70fcb15d1bea369ec upstream. Flexible-array member `hws` in `struct clk_hw_onecell_data` is annotated with the `counted_by()` attribute. This means that when memory is allocated for this array, the _counter_, which in this case is member `num` in the flexible structure, should be set to the maximum number of elements the flexible array can contain, or fewer. In this case, the total number of elements for the flexible array is determined by variable `clks_num` when allocating heap space via `devm_kzalloc()`, as shown below: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); So, `clp->clk_data.num` should be set to `clks_num` or less, and not exceed `clks_num`, as is currently the case. Otherwise, if data is written into `clp->clk_data.hws[clks_num]`, the instrumentation provided by the compiler won't detect the overflow, leading to a memory corruption bug at runtime. Fix this issue by setting `clp->clk_data.num` to `clks_num`. Fixes: 9796ec0b ("clk: clk-loongson2: Refactor driver for adding new platforms") Cc: stable@vger.kernel.org Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/ZzaN5MpmMr0hwHw9@kspp Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Gustavo A. R. Silva authored
commit 6e4bf018bb040955da53dae9f8628ef8fcec2dbe upstream. Some heap space is allocated for the flexible structure `struct clk_hw_onecell_data` and its flexible-array member `hws` through the composite structure `struct loongson2_clk_provider` in function `loongson2_clk_probe()`, as shown below: 289 struct loongson2_clk_provider *clp; ... 296 for (p = data; p->name; p++) 297 clks_num++; 298 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num), 300 GFP_KERNEL); Then some data is written into the flexible array: 350 clp->clk_data.hws[p->id] = hw; This corrupts `clk_lock`, which is the spinlock variable immediately following the `clk_data` member in `struct loongson2_clk_provider`: struct loongson2_clk_provider { void __iomem *base; struct device *dev; struct clk_hw_onecell_data clk_data; spinlock_t clk_lock; /* protect access to DIV registers */ }; The problem is that the flexible structure is currently placed in the middle of `struct loongson2_clk_provider` instead of at the end. Fix this by moving `struct clk_hw_onecell_data clk_data;` to the end of `struct loongson2_clk_provider`. Also, add a code comment to help prevent this from happening again in case new members are added to the structure in the future. This change also fixes the following -Wflex-array-member-not-at-end warning: drivers/clk/clk-loongson2.c:32:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end] Fixes: 9796ec0b ("clk: clk-loongson2: Refactor driver for adding new platforms") Cc: stable@vger.kernel.org Signed-off-by: -
Huacai Chen authored
commit e67e0eb6a98b261caf45048f9eb95fd7609289c0 upstream. LoongArch's toolchain may change the default code model from normal to medium. This is unnecessary for kernel, and generates some relocations which cannot be handled by the module loader. So explicitly specify the code model to normal in Makefile (for Rust 'normal' is 'small'). Cc: stable@vger.kernel.org Tested-by:
Haiyong Sun <sunhaiyong@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn> Signed-off-by:
-
Lukas Wunner authored
commit c7acef99642b763ba585f4a43af999fcdbcc3dc4 upstream. Dennis reports a boot crash on recent Lenovo laptops with a USB4 dock. Since commit 0fc70886 ("thunderbolt: Reset USB4 v2 host router") and commit 59a54c5f ("thunderbolt: Reset topology created by the boot firmware"), USB4 v2 and v1 Host Routers are reset on probe of the thunderbolt driver. The reset clears the Presence Detect State and Data Link Layer Link Active bits at the USB4 Host Router's Root Port and thus causes hot removal of the dock. The crash occurs when pciehp is unbound from one of the dock's Downstream Ports: pciehp creates a pci_slot on bind and destroys it on unbind. The pci_slot contains a pointer to the pci_bus below the Downstream Port, but a reference on that pci_bus is never acquired. The pci_bus is destroyed before the pci_slot, so a use-after-free ensues when pci_slot_release() accesses slot->bus. In principle this should not happen because pci_stop_bus_device() unbinds pciehp (and therefore destroys the pci_slot) before the pci_bus is destroyed by pci_remove_bus_device(). However the stacktrace provided by Dennis shows that pciehp is unbound from pci_remove_bus_device() instead of pci_stop_bus_device(). To understand the significance of this, one needs to know that the PCI core uses a two step process to remove a portion of the hierarchy: It first unbinds all drivers in the sub-hierarchy in pci_stop_bus_device() and then actually removes the devices in pci_remove_bus_device(). There is no precaution to prevent driver binding in-between pci_stop_bus_device() and pci_remove_bus_device(). In Dennis' case, it seems removal of the hierarchy by pciehp races with driver binding by pci_bus_add_devices(). pciehp is bound to the Downstream Port after pci_stop_bus_device() has run, so it is unbound by pci_remove_bus_device() instead of pci_stop_bus_device(). Because the pci_bus has already been destroyed at that point, accesses to it result in a use-after-free. One might conclude that driver binding needs to be prevented after pci_stop_bus_device() has run. However it seems risky that pci_slot points to pci_bus without holding a reference. Solely relying on correct ordering of driver unbind versus pci_bus destruction is certainly not defensive programming. If pci_slot has a need to access data in pci_bus, it ought to acquire a reference. Amend pci_create_slot() accordingly. Dennis reports that the crash is not reproducible with this change. Abridged stacktrace: pcieport 0000:00:07.0: PME: Signaling with IRQ 156 pcieport 0000:00:07.0: pciehp: Slot #12 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+ pci_bus 0000:20: dev 00, created physical slot 12 pcieport 0000:00:07.0: pciehp: Slot(12): Card not present ... pcieport 0000:21:02.0: pciehp: pcie_disable_notification: SLOTCTRL d8 write cmd 0 Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI CPU: 13 UID: 0 PID: 134 Comm: irq/156-pciehp Not tainted 6.11.0-devel+ #1 RIP: 0010:dev_driver_string+0x12/0x40 pci_destroy_slot pciehp_remove pcie_port_remove_service device_release_driver_internal bus_remove_device device_del device_unregister remove_iter device_for_each_child pcie_portdrv_remove pci_device_remove device_release_driver_internal bus_remove_device device_del pci_remove_bus_device (recursive invocation) pci_remove_bus_device pciehp_unconfigure_device pciehp_disable_slot pciehp_handle_presence_or_link_change pciehp_ist Link: https://lore.kernel.org/r/4bfd4c0e976c1776cd08e76603903b338cf25729.1728579288.git.lukas@wunner.de Reported-by:
Dennis Wassenberg <Dennis.Wassenberg@secunet.com> Closes: https://lore.kernel.org/r/6de4b45ff2b32dd91a805ec02ec8ec73ef411bf6.camel@secunet.com/ Tested-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Jan Hendrik Farr authored
commit f06e108a3dc53c0f5234d18de0bd224753db5019 upstream. This patch disables __counted_by for clang versions < 19.1.3 because of the two issues listed below. It does this by introducing CONFIG_CC_HAS_COUNTED_BY. 1. clang < 19.1.2 has a bug that can lead to __bdos returning 0: https://github.com/llvm/llvm-project/pull/110497 2. clang < 19.1.3 has a bug that can lead to __bdos being off by 4: https://github.com/llvm/llvm-project/pull/112636 Fixes: c8248faf ("Compiler Attributes: counted_by: Adjust name and identifier expansion") Cc: stable@vger.kernel.org # 6.6.x: 16c31dd7: Compiler Attributes: counted_by: bump min gcc version Cc: stable@vger.kernel.org # 6.6.x: 2993eb7a: Compiler Attributes: counted_by: fixup clang URL Cc: stable@vger.kernel.org # 6.6.x: 231dc3f0: lkdtm/bugs: Improve warning message for compilers without counted_by support Cc: stable@vger.kernel.org # 6.6.x Reported-by:
Nathan Chancellor <nathan@kernel.org> Closes: https://lore.kernel.org/all/20240913164630.GA4091534@thelio-3990X/ Reported-by:
kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202409260949.a1254989-oliver.sang@intel.com Link: https://lore.kernel.org/all/Zw8iawAF5W2uzGuh@archlinux/T/#m204c09f63c076586a02d194b87dffc7e81b8de7b Suggested-by:
Jan Hendrik Farr <kernel@jfarr.cc> Reviewed-by:
Miguel Ojeda <ojeda@kernel.org> Reviewed-by:
Thorsten Blum <thorsten.blum@linux.dev> Link: https://lore.kernel.org/r/20241029140036.577804-2-kernel@jfarr.cc Signed-off-by:
Kees Cook <kees@kernel.org> Signed-off-by:
-
Kunkun Jiang authored
commit e9649129d33dca561305fc590a7c4ba8c3e5675a upstream. vgic_its_save_device_tables will traverse its->device_list to save DTE for each device. vgic_its_restore_device_tables will traverse each entry of device table and check if it is valid. Restore if valid. But when MAPD unmaps a device, it does not invalidate the corresponding DTE. In the scenario of continuous saves and restores, there may be a situation where a device's DTE is not saved but is restored. This is unreasonable and may cause restore to fail. This patch clears the corresponding DTE when MAPD unmaps a device. Cc: stable@vger.kernel.org Fixes: 57a9a117 ("KVM: arm64: vgic-its: Device table save/restore") Co-developed-by:
Shusen Li <lishusen2@huawei.com> Signed-off-by:
Kunkun Jiang <jiangkunkun@huawei.com> [Jing: Update with entry write helper] Signed-off-by:
Jing Zhang <jingzhangos@google.com> Link: https://lore.kernel.org/r/20241107214137.428439-5-jingzhangos@google.com Signed-off-by:
Oliver Upton <oliver.upton@linux.dev> Signed-off-by:
-
Jing Zhang authored
commit 7fe28d7e68f92cc3d0668b8f2fbdf5c303ac3022 upstream. In all the vgic_its_save_*() functinos, they do not check whether the data length is 8 bytes before calling vgic_write_guest_lock. This patch adds the check. To prevent the kernel from being blown up when the fault occurs, KVM_BUG_ON() is used. And the other BUG_ON()s are replaced together. Cc: stable@vger.kernel.org Signed-off-by:
-
Raghavendra Rao Ananta authored
commit 38d7aacca09230fdb98a34194fec2af597e8e20d upstream. Improper use of userspace_irqchip_in_use led to syzbot hitting the following WARN_ON() in kvm_timer_update_irq(): WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459 kvm_timer_update_irq+0x21c/0x394 Call trace: kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459 kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968 kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264 kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline] kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline] kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695 kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 The following sequence led to the scenario: - Userspace creates a VM and a vCPU. - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during KVM_ARM_VCPU_INIT. - Without any other setup, such as vGIC or vPMU, userspace issues KVM_RUN on the vCPU. Since the vPMU is requested, but not setup, kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change(). As a result, KVM_RUN returns after enabling the timer, but before incrementing 'userspace_irqchip_in_use': kvm_arch_vcpu_run_pid_change() ret = kvm_arm_pmu_v3_enable() if (!vcpu->arch.pmu.created) return -EINVAL; if (ret) return ret; [...] if (!irqchip_in_kernel(kvm)) static_branch_inc(&userspace_irqchip_in_use); - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again. Since the timer is already enabled, control moves through the following flow, ultimately hitting the WARN_ON(): kvm_timer_vcpu_reset() if (timer->enabled) kvm_timer_update_irq() if (!userspace_irqchip()) ret = kvm_vgic_inject_irq() ret = vgic_lazy_init() if (unlikely(!vgic_initialized(kvm))) if (kvm->arch.vgic.vgic_model != KVM_DEV_TYPE_ARM_VGIC_V2) return -EBUSY; WARN_ON(ret); Theoretically, since userspace_irqchip_in_use's functionality can be simply replaced by '!irqchip_in_kernel()', get rid of the static key to avoid the mismanagement, which also helps with the syzbot issue. Cc: <stable@vger.kernel.org> Reported-by:syzbot <syzkaller@googlegroups.com> Suggested-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Raghavendra Rao Ananta <rananta@google.com> Signed-off-by:
-
Kunkun Jiang authored
commit 7602ffd1d5e8927fadd5187cb4aed2fdc9c47143 upstream. When DISCARD frees an ITE, it does not invalidate the corresponding ITE. In the scenario of continuous saves and restores, there may be a situation where an ITE is not saved but is restored. This is unreasonable and may cause restore to fail. This patch clears the corresponding ITE when DISCARD frees an ITE. Cc: stable@vger.kernel.org Fixes: eff484e0 ("KVM: arm64: vgic-its: ITT save and restore") Signed-off-by:
-
Oliver Upton authored
commit e735a5da64420a86be370b216c269b5dd8e830e2 upstream. Returning an abort to the guest for an unsupported MMIO access is a documented feature of the KVM UAPI. Nevertheless, it's clear that this plumbing has seen limited testing, since userspace can trivially cause a WARN in the MMIO return: WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 The splat is complaining that KVM is advancing PC while an exception is pending, i.e. that KVM is retiring the MMIO instruction despite a pending synchronous external abort. Womp womp. Fix the glaring UAPI bug by skipping over all the MMIO emulation in case there is a pending synchronous exception. Note that while userspace is capable of pending an asynchronous exception (SError, IRQ, or FIQ), it is still safe to retire the MMIO instruction in this case as (1) they are by definition asynchronous, and (2) KVM relies on hardware support for pending/delivering these exceptions instead of the software state machine for advancing PC. Cc: stable@vger.kernel.org Fixes: da345174 ("KVM: arm/arm64: Allow user injection of external data aborts") Reported-by:
Alexander Potapenko <glider@google.com> Reviewed-by:
-
Sean Christopherson authored
commit 85434c3c73fcad58870016ddfe5eaa5036672675 upstream. Revert back to clearing VM_{ENTRY,EXIT}_LOAD_IA32_PERF_GLOBAL_CTRL in KVM's golden VMCS config, as applying the workaround during vCPU creation is pointless and broken. KVM *unconditionally* clears the controls in the values returned by vmx_vmentry_ctrl() and vmx_vmexit_ctrl(), as KVM loads PERF_GLOBAL_CTRL if and only if its necessary to do so. E.g. if KVM wants to run the guest with the same PERF_GLOBAL_CTRL as the host, then there's no need to re-load the MSR on entry and exit. Even worse, the buggy commit failed to apply the erratum where it's actually needed, add_atomic_switch_msr(). As a result, KVM completely ignores the erratum for all intents and purposes, i.e. uses the flawed VMCS controls to load PERF_GLOBAL_CTRL. To top things off, the patch was intended to be dropped, as the premise of an L1 VMM being able to pivot on FMS is flawed, and KVM can (and now does) fully emulate the controls in software. Simply revert the commit, as all upstream supported kernels that have the buggy commit should also have commit f4c93d1a ("KVM: nVMX: Always emulate PERF_GLOBAL_CTRL VM-Entry/VM-Exit controls"), i.e. the (likely theoretical) live migration concern is a complete non-issue. Opportunistically drop the manual "kvm: " scope from the warning about the erratum, as KVM now uses pr_fmt() to provide the correct scope (v6.1 kernels and earlier don't, but the erratum only applies to CPUs that are 15+ years old; it's not worth a separate patch). This reverts commit 9d78d6fb. Link: https://lore.kernel.org/all/YtnZmCutdd5tpUmz@google.com Fixes: 9d78d6fb ("KVM: VMX: Move LOAD_IA32_PERF_GLOBAL_CTRL errata handling out of setup_vmcs_config()") Cc: stable@vger.kernel.org Cc: Vitaly Kuznetsov <vkuznets@redhat.com> Cc: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by:Sean Christopherson <seanjc@google.com> Reviewed-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Message-ID: <20241119011433.1797921-1-seanjc@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Raghavendra Rao Ananta authored
commit 54bbee190d42166209185d89070c58a343bf514b upstream. DDI0487K.a D13.3.1 describes the PMU overflow condition, which evaluates to true if any counter's global enable (PMCR_EL0.E), overflow flag (PMOVSSET_EL0[n]), and interrupt enable (PMINTENSET_EL1[n]) are all 1. Of note, this does not require a counter to be enabled (i.e. PMCNTENSET_EL0[n] = 1) to generate an overflow. Align kvm_pmu_overflow_status() with the reality of the architecture and stop using PMCNTENSET_EL0 as part of the overflow condition. The bug was discovered while running an SBSA PMU test [*], which only sets PMCR.E, PMOVSSET<0>, PMINTENSET<0>, and expects an overflow interrupt. Cc: stable@vger.kernel.org Fixes: 76d883c4 ("arm64: KVM: Add access handler for PMOVSSET and PMOVSCLR register") Link: https://github.com/ARM-software/sbsa-acs/blob/master/test_pool/pmu/operating_system/test_pmu001.c Signed-off-by:
-
Marc Zyngier authored
commit d561491ba927cb5634094ff311795e9d618e9b86 upstream. Make sure we filter out non-LPI invalidation when handling writes to GICR_INVLPIR. Fixes: 4645d11f ("KVM: arm64: vgic-v3: Implement MMIO-based LPI invalidation") Reported-by:
-
Gautam Menghani authored
commit 44e5d21e6d3fd2a1fed7f0327cf72e99397e2eaf upstream. As per the kernel documentation[1], hardlockup detector should be disabled in KVM guests as it may give false positives. On PPC, hardlockup detector is enabled inside KVM guests because disable_hardlockup_detector() is marked as early_initcall and it relies on kvm_guest static key (is_kvm_guest()) which is initialized later during boot by check_kvm_guest(), which is a core_initcall. check_kvm_guest() is also called in pSeries_smp_probe(), which is called before initcalls, but it is skipped if KVM guest does not have doorbell support or if the guest is launched with SMT=1. Call check_kvm_guest() in disable_hardlockup_detector() so that is_kvm_guest() check goes through fine and hardlockup detector can be disabled inside the KVM guest. [1]: Documentation/admin-guide/sysctl/kernel.rst Fixes: 633c8e98 ("powerpc/pseries: Enable hardlockup watchdog for PowerVM partitions") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by:
Gautam Menghani <gautam@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://patch.msgid.link/20241108094839.33084-1-gautam@linux.ibm.com Signed-off-by:
-
Sean Christopherson authored
commit 9ee62c33c0fe017ee02501a877f6f562363122fa upstream. Rework CONFIG_KVM_X86's dependency to only check if KVM_INTEL or KVM_AMD is selected, i.e. not 'n'. Having KVM_X86 depend directly on the vendor modules results in KVM_X86 being set to 'm' if at least one of KVM_INTEL or KVM_AMD is enabled, but neither is 'y', regardless of the value of KVM itself. The documentation for def_tristate doesn't explicitly state that this is the intended behavior, but it does clearly state that the "if" section is parsed as a dependency, i.e. the behavior is consistent with how tristate dependencies are handled in general. Optionally dependencies for this default value can be added with "if". Fixes: ea4290d7 ("KVM: x86: leave kvm.ko out of the build if no vendor module is requested") Cc: stable@vger.kernel.org Signed-off-by:
-
Arnd Bergmann authored
commit 1331343af6f502aecd274d522dd34bf7c965f484 upstream. Enabling KVM now causes a build failure on x86-32 if X86_LOCAL_APIC is disabled: arch/x86/kvm/svm/svm.c: In function 'svm_emergency_disable_virtualization_cpu': arch/x86/kvm/svm/svm.c:597:9: error: 'kvm_rebooting' undeclared (first use in this function); did you mean 'kvm_irq_routing'? 597 | kvm_rebooting = true; | ^~~~~~~~~~~~~ | kvm_irq_routing arch/x86/kvm/svm/svm.c:597:9: note: each undeclared identifier is reported only once for each function it appears in make[6]: *** [scripts/Makefile.build:221: arch/x86/kvm/svm/svm.o] Error 1 In file included from include/linux/rculist.h:11, from include/linux/hashtable.h:14, from arch/x86/kvm/svm/avic.c:18: arch/x86/kvm/svm/avic.c: In function 'avic_pi_update_irte': arch/x86/kvm/svm/avic.c:909:38: error: 'struct kvm' has no member named 'irq_routing' 909 | irq_rt = srcu_dereference(kvm->irq_routing, &kvm->irq_srcu); | ^~ include/linux/rcupdate.h:538:17: note: in definition of macro '__rcu_dereference_check' 538 | typeof(*p) *local = (typeof(*p) *__force)READ_ONCE(p); \ Move the dependency to the same place as before. Fixes: ea4290d7 ("KVM: x86: leave kvm.ko out of the build if no vendor module is requested") Cc: stable@vger.kernel.org Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202410060426.e9Xsnkvi-lkp@intel.com/ Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
-
Sean Christopherson authored
commit 2867eb782cf7f64c2ac427596133b6f9c3f64b7a upstream. Apply make_spte()'s optimization to skip trying to unsync shadow pages if and only if the old SPTE was a leaf SPTE, as non-leaf SPTEs in direct MMUs are always writable, i.e. could trigger a false positive and incorrectly lead to KVM creating a SPTE without write-protecting or marking shadow pages unsync. This bug only affects the TDP MMU, as the shadow MMU only overwrites a shadow-present SPTE when synchronizing SPTEs (and only 4KiB SPTEs can be unsync). Specifically, mmu_set_spte() drops any non-leaf SPTEs *before* calling make_spte(), whereas the TDP MMU can do a direct replacement of a page table with the leaf SPTE. Opportunistically update the comment to explain why skipping the unsync stuff is safe, as opposed to simply saying "it's someone else's problem". Cc: stable@vger.kernel.org Tested-by:
Alex Bennée <alex.bennee@linaro.org> Signed-off-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
-
Paolo Bonzini authored
commit d96c77bd4eeba469bddbbb14323d2191684da82a upstream. kvm_vm_create_worker_thread() is meant to be used for kthreads that can consume significant amounts of CPU time on behalf of a VM or in response to how the VM behaves (for example how it accesses its memory). Therefore it wants to charge the CPU time consumed by that work to the VM's container. However, because of these threads, cgroups which have kvm instances inside never complete freezing. This can be trivially reproduced: root@test ~# mkdir /sys/fs/cgroup/test root@test ~# echo $$ > /sys/fs/cgroup/test/cgroup.procs root@test ~# qemu-system-x86_64 -nographic -enable-kvm and in another terminal: root@test ~# echo 1 > /sys/fs/cgroup/test/cgroup.freeze root@test ~# cat /sys/fs/cgroup/test/cgroup.events populated 1 frozen 0 The cgroup freezing happens in the signal delivery path but kvm_nx_huge_page_recovery_worker, while joining non-root cgroups, never calls into the signal delivery path and thus never gets frozen. Because the cgroup freezer determines whether a given cgroup is frozen by comparing the number of frozen threads to the total number of threads in the cgroup, the cgroup never becomes frozen and users waiting for the state transition may hang indefinitely. Since the worker kthread is tied to a user process, it's better if it behaves similarly to user tasks as much as possible, including being able to send SIGSTOP and SIGCONT. In fact, vhost_task is all that kvm_vm_create_worker_thread() wanted to be and more: not only it inherits the userspace process's cgroups, it has other niceties like being parented properly in the process tree. Use it instead of the homegrown alternative. Incidentally, the new code is also better behaved when you flip recovery back and forth to disabled and back to enabled. If your recovery period is 1 minute, it will run the next recovery after 1 minute independent of how many times you flipped the parameter. (Commit message based on emails from Tejun). Reported-by:
Tejun Heo <tj@kernel.org> Reported-by:
Luca Boccassi <bluca@debian.org> Acked-by:
-
Eric Biggers authored
commit 3b2f2d22fb424e9bebda4dbf6676cbfc7f9f62cd upstream. Fix the AEGIS assembly code to access 'unsigned int' arguments as 32-bit values instead of 64-bit, since the upper bits of the corresponding 64-bit registers are not guaranteed to be zero. Note: there haven't been any reports of this bug actually causing incorrect behavior. Neither gcc nor clang guarantee zero-extension to 64 bits, but zero-extension is likely to happen in practice because most instructions that operate on 32-bit registers zero-extend to 64 bits. Fixes: 1d373d4e ("crypto: x86 - Add optimized AEGIS implementations") Cc: stable@vger.kernel.org Reviewed-by:
Ondrej Mosnacek <omosnace@redhat.com> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Adrian Hunter authored
commit 5b590160d2cf776b304eb054afafea2bd55e3620 upstream. If the trace data buffer becomes full, a truncated flag [T] is reported in PERF_RECORD_AUX. In some cases, the size reported is 0, even though data must have been added to make the buffer full. That happens when the buffer fills up from empty to full before the Intel PT driver has updated the buffer position. Then the driver calculates the new buffer position before calculating the data size. If the old and new positions are the same, the data size is reported as 0, even though it is really the whole buffer size. Fix by detecting when the buffer position is wrapped, and adjust the data size calculation accordingly. Example Use a very small buffer size (8K) and observe the size of truncated [T] data. Before the fix, it is possible to see records of 0 size. Before: $ perf record -m,8K -e intel_pt// uname Linux [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.105 MB perf.data ] $ perf script -D --no-itrace | grep AUX | grep -F '[T]' Warning: AUX data lost 2 times out of 3! 5 19462712368111 0x19710 [0x40]: PERF_RECORD_AUX offset: 0 size: 0 flags: 0x1 [T] 5 19462712700046 0x19ba8 [0x40]: PERF_RECORD_AUX offset: 0x170 size: 0xe90 flags: 0x1 [T] After: $ perf record -m,8K -e intel_pt// uname Linux [ perf record: Woken up 3 times to write data ] [ perf record: Captured and wrote 0.040 MB perf.data ] $ perf script -D --no-itrace | grep AUX | grep -F '[T]' Warning: AUX data lost 2 times out of 3! 1 113720802995 0x4948 [0x40]: PERF_RECORD_AUX offset: 0 size: 0x2000 flags: 0x1 [T] 1 113720979812 0x6b10 [0x40]: PERF_RECORD_AUX offset: 0x2000 size: 0x2000 flags: 0x1 [T] Fixes: 52ca9ced ("perf/x86/intel/pt: Add Intel PT PMU driver") Signed-off-by:Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20241022155920.17511-2-adrian.hunter@intel.com Signed-off-by:
-
Claudiu Beznea authored
commit 9d4f9f6a7bb1afbde57d08c98f2db4ff019ee19d upstream. On the Renesas RZ/G3S SMARC Carrier II board having a DA7212 codec (using da7213 driver) connected to one SSIF-2 available on the Renesas RZ/G3S SoC it has been discovered that using the runtime PM API for suspend/resume (as will be proposed in the following commits) leads to the codec not being propertly initialized after resume. This is because w/o max_register populated to regmap_config the regcache_rbtree_sync() breaks on base_reg > max condition and the regcache_sync_block() call is skipped. Fixes: ef5c2eba ("ASoC: codecs: Add da7213 codec") Cc: stable@vger.kernel.org Signed-off-by:
Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20241106081826.1211088-23-claudiu.beznea.uj@bp.renesas.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Qiu-ji Chen authored
commit 1157733344651ca505e259d6554591ff156922fa upstream. An atomicity violation occurs when the validity of the variables da7219->clk_src and da7219->mclk_rate is being assessed. Since the entire assessment is not protected by a lock, the da7219 variable might still be in flux during the assessment, rendering this check invalid. To fix this issue, we recommend adding a lock before the block if ((da7219->clk_src == clk_id) && (da7219->mclk_rate == freq)) so that the legitimacy check for da7219->clk_src and da7219->mclk_rate is protected by the lock, ensuring the validity of the check. This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations. Fixes: 6d817c0e ("ASoC: codecs: Add da7219 codec driver") Cc: stable@vger.kernel.org Signed-off-by:
Qiu-ji Chen <chenqiuji666@gmail.com> Link: https://patch.msgid.link/20240930101216.23723-1-chenqiuji666@gmail.com Signed-off-by:
-
Ilya Zverev authored
commit b682aa788e5f9f1ddacdfbb453e49fd3f4e83721 upstream. New ThinkPads need new quirk entries. Ilya has tested this one. Laptop product id is 21MES00B00, though the shorthand 21ME works. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219533 Cc: stable@vger.kernel.org Signed-off-by:
Ilya Zverev <ilya@zverev.info> Link: https://patch.msgid.link/20241127134420.14471-1-ilya@zverev.info Signed-off-by:
-
Artem Sadovnikov authored
commit d9f9d96136cba8fedd647d2c024342ce090133c2 upstream. Commit 7c55b788 ("jfs: xattr: fix buffer overflow for invalid xattr") also addresses this issue but it only fixes it for positive values, while ea_size is an integer type and can take negative values, e.g. in case of a corrupted filesystem. This still breaks validation and would overflow because of implicit conversion from int to size_t in print_hex_dump(). Fix this issue by clamping the ea_size value instead. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Cc: stable@vger.kernel.org Signed-off-by:
Artem Sadovnikov <ancowi69@gmail.com> Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 72ad4ff638047bbbdf3232178fea4bec1f429319 upstream. Due to recent changes on the way we're maintaining media, the location of the main tree was updated. Change docs accordingly. Cc: stable@vger.kernel.org Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by:
Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit dc51b3cc9d4d2a04bdbfe34f7746fc9122cc3f49 upstream. There were some recent changes on the way we're handling media patches. Now, the official tree is located at: https://git.linuxtv.org/media.git/ Update it at MAINTAINERS file. Cc: stable@vger.kernel.org Signed-off-by:
-
Theodore Ts'o authored
commit 4a622e4d477bb12ad5ed4abbc7ad1365de1fa347 upstream. The original implementation ext4's FS_IOC_GETFSMAP handling only worked when the range of queried blocks included at least one free (unallocated) block range. This is because how the metadata blocks were emitted was as a side effect of ext4_mballoc_query_range() calling ext4_getfsmap_datadev_helper(), and that function was only called when a free block range was identified. As a result, this caused generic/365 to fail. Fix this by creating a new function ext4_getfsmap_meta_helper() which gets called so that blocks before the first free block range in a block group can get properly reported. Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@vger.kernel.org Signed-off-by:
-
Jeongjun Park authored
commit 902cc179c931a033cd7f4242353aa2733bf8524c upstream. find_group_other() and find_group_orlov() read *_lo, *_hi with ext4_free_inodes_count without additional locking. This can cause data-race warning, but since the lock is held for most writes and free inodes value is generally not a problem even if it is incorrect, it is more appropriate to use READ_ONCE()/WRITE_ONCE() than to add locking. ================================================================== BUG: KCSAN: data-race in ext4_free_inodes_count / ext4_free_inodes_set write to 0xffff88810404300e of 2 bytes by task 6254 on cpu 1: ext4_free_inodes_set+0x1f/0x80 fs/ext4/super.c:405 __ext4_new_inode+0x15ca/0x2200 fs/ext4/ialloc.c:1216 ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391 vfs_symlink+0xca/0x1d0 fs/namei.c:4615 do_symlinkat+0xe3/0x340 fs/namei.c:4641 __do_sys_symlinkat fs/namei.c:4657 [inline] __se_sys_symlinkat fs/namei.c:4654 [inline] __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654 x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e read to 0xffff88810404300e of 2 bytes by task 6257 on cpu 0: ext4_free_inodes_count+0x1c/0x80 fs/ext4/super.c:349 find_group_other fs/ext4/ialloc.c:594 [inline] __ext4_new_inode+0x6ec/0x2200 fs/ext4/ialloc.c:1017 ext4_symlink+0x242/0x5a0 fs/ext4/namei.c:3391 vfs_symlink+0xca/0x1d0 fs/namei.c:4615 do_symlinkat+0xe3/0x340 fs/namei.c:4641 __do_sys_symlinkat fs/namei.c:4657 [inline] __se_sys_symlinkat fs/namei.c:4654 [inline] __x64_sys_symlinkat+0x5e/0x70 fs/namei.c:4654 x64_sys_call+0x1dda/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:267 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x54/0x120 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7e Cc: stable@vger.kernel.org Signed-off-by:
Jeongjun Park <aha310510@gmail.com> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Link: https://patch.msgid.link/20241003125337.47283-1-aha310510@gmail.com Signed-off-by:
-
Darrick J. Wong authored
commit 62027820eb4486f075b89ec31c1548c6cb1bb13f upstream. In commit 11f4c3a5, we tried to simplify the extent lookup in xfs_can_free_eofblocks so that it doesn't incur the overhead of all the extra stuff that xfs_bmapi_read does around the iext lookup. Unfortunately, this causes regressions on generic/603, xfs/108, generic/219, xfs/173, generic/694, xfs/052, generic/230, and xfs/441 when always_cow is turned on. In all cases, the regressions take the form of alwayscow files consuming rather more space than the golden output is expecting. I observed that in all these cases, the cause of the excess space usage was due to CoW fork delalloc reservations that go beyond EOF. For alwayscow files we allow posteof delalloc CoW reservations because all writes go through the CoW fork. Recall that all extents in the CoW fork are accounted for via i_delayed_blks, which means that prior to this patch, we'd invoke xfs_free_eofblocks on first close if anything was in the CoW fork. Now we don't do that. Fix the problem by reverting the removal of the i_delayed_blks check. Cc: <stable@vger.kernel.org> # v6.12-rc1 Fixes: 11f4c3a5 ("xfs: simplify extent lookup in xfs_can_free_eofblocks") Signed-off-by:
Darrick J. Wong <djwong@kernel.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
