summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-11-05ext4: Add statx support for atomic writesRitesh Harjani (IBM)
This patch adds base support for atomic writes via statx getattr. On bs < ps systems, we can create FS with say bs of 16k. That means both atomic write min and max unit can be set to 16k for supporting atomic writes. Co-developed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com> Signed-off-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Jan Kara <jack@suse.cz>
2024-11-05md/raid5: don't set Faulty rdev for blocked_rdevYu Kuai
Faulty rdev should never be accessed anymore, hence there is no point to wait for bad block to be acknowledged in this case while handling write request. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Tested-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> Link: https://lore.kernel.org/r/20241031033114.3845582-8-yukuai1@huaweicloud.com Signed-off-by: Song Liu <song@kernel.org>
2024-11-05md/raid10: don't wait for Faulty rdev in wait_blocked_rdev()Yu Kuai
Faulty rdev should never be accessed anymore, hence there is no point to wait for bad block to be acknowledged in this case while handling write request. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Tested-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> Link: https://lore.kernel.org/r/20241031033114.3845582-7-yukuai1@huaweicloud.com Signed-off-by: Song Liu <song@kernel.org>
2024-11-05md/raid1: don't wait for Faulty rdev in wait_blocked_rdev()Yu Kuai
Faulty rdev should never be accessed anymore, hence there is no point to wait for bad block to be acknowledged in this case while handling write request. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Tested-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> Link: https://lore.kernel.org/r/20241031033114.3845582-6-yukuai1@huaweicloud.com Signed-off-by: Song Liu <song@kernel.org>
2024-11-05md/raid1: factor out helper to handle blocked rdev from raid1_write_request()Yu Kuai
Currently raid1 is preparing IO for underlying disks while checking if any disk is blocked, if so allocated resources must be released, then waiting for rdev to be unblocked and try to prepare IO again. Make code cleaner by checking blocked rdev first, it doesn't matter if rdev is blocked while issuing IO, the IO will wait for rdev to be unblocked or not. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Tested-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> Link: https://lore.kernel.org/r/20241031033114.3845582-5-yukuai1@huaweicloud.com Signed-off-by: Song Liu <song@kernel.org>
2024-11-05md: don't record new badblocks for faulty rdevYu Kuai
Faulty will be checked before issuing IO to the rdev, however, rdev can be faulty at any time, hence it's possible that rdev_set_badblocks() will be called for faulty rdev. In this case, mddev->sb_flags will be set and some other path can be blocked by updating super block. Since faulty rdev will not be accesed anymore, there is no need to record new babblocks for faulty rdev and forcing updating super block. Noted this is not a bugfix, just prevent updating superblock in some corner cases, and will help to slice a bug related to external metadata[1], testing also shows that devices are removed faster in the case IO error. [1] https://lore.kernel.org/all/f34452df-810b-48b2-a9b4-7f925699a9e7@linux.intel.com/ Signed-off-by: Yu Kuai <yukuai3@huawei.com> Tested-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> Link: https://lore.kernel.org/r/20241031033114.3845582-4-yukuai1@huaweicloud.com Signed-off-by: Song Liu <song@kernel.org>
2024-11-05md: don't wait faulty rdev in md_wait_for_blocked_rdev()Yu Kuai
md_wait_for_blocked_rdev() is called for write IO while rdev is blocked, howerver, rdev can be faulty after choosing this rdev to write, and faulty rdev should never be accessed anymore, hence there is no point to wait for faulty rdev to be unblocked. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Tested-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> Link: https://lore.kernel.org/r/20241031033114.3845582-3-yukuai1@huaweicloud.com Signed-off-by: Song Liu <song@kernel.org>
2024-11-05md: add a new helper rdev_blocked()Yu Kuai
The helper will be used in later patches for raid1/raid10/raid5, the difference is that Faulty rdev with unacknowledged bad block will not be considered blocked. Signed-off-by: Yu Kuai <yukuai3@huawei.com> Tested-by: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com> Link: https://lore.kernel.org/r/20241031033114.3845582-2-yukuai1@huaweicloud.com Signed-off-by: Song Liu <song@kernel.org>
2024-11-05md/raid5-ppl: Use atomic64_inc_return() in ppl_new_iounit()Uros Bizjak
Use atomic64_inc_return(&ref) instead of atomic64_add_return(1, &ref) to use optimized implementation and ease register pressure around the primitive for targets that implement optimized variant. Signed-off-by: Uros Bizjak <ubizjak@gmail.com> Cc: Song Liu <song@kernel.org> Cc: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Yu Kuai <yukuai3@huawei.com> Reviewed-by: Artur Paszkiewicz <artur.paszkiewicz@intel.com> Link: https://lore.kernel.org/r/20241007084831.48067-1-ubizjak@gmail.com Signed-off-by: Song Liu <song@kernel.org>
2024-11-05drm/xe: Stop accumulating LRC timestamp on job_freeLucas De Marchi
The exec queue timestamp is only really useful when it's being queried through the fdinfo. There's no need to update it so often, on every job_free. Tracing a simple app like vkcube running shows an update rate of ~ 120Hz. In case of discrete, the BO is on vram, creating a lot of pcie transactions. The update on job_free() is used to cover a gap: if exec queue is created and destroyed rapidly, before a new query, the timestamp still needs to be accumulated and accounted for in the xef. Initial implementation in commit 6109f24f87d7 ("drm/xe: Add helper to accumulate exec queue runtime") couldn't do it on the exec_queue_fini since the xef could be gone at that point. However since commit ce8c161cbad4 ("drm/xe: Add ref counting for xe_file") the xef is refcounted and the exec queue always holds a reference, making this safe now. Improve the fix in commit 2149ded63079 ("drm/xe: Fix use after free when client stats are captured") by reducing the frequency in which the update is needed. Fixes: 2149ded63079 ("drm/xe: Fix use after free when client stats are captured") Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241104143815.2112272-3-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit 83db047d9425d9a649f01573797558eff0f632e1) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-11-05drm/xe/pf: Fix potential GGTT allocation leakMichal Wajdeczko
In unlikely event that we fail during sending the new VF GGTT configuration to the GuC, we will free only the GGTT node data struct but will miss to release the actual GGTT allocation. This will later lead to list corruption, GGTT space leak and finally risking crash when unloading the driver: [ ] ... [drm] GT0: PF: Failed to provision VF1 with 1073741824 (1.00 GiB) GGTT (-EIO) [ ] ... [drm] GT0: PF: VF1 provisioning remains at 0 (0 B) GGTT [ ] list_add corruption. next->prev should be prev (ffff88813cfcd628), but was 0000000000000000. (next=ffff88813cfe2028). [ ] RIP: 0010:__list_add_valid_or_report+0x6b/0xb0 [ ] Call Trace: [ ] drm_mm_insert_node_in_range+0x2c0/0x4e0 [ ] xe_ggtt_node_insert+0x46/0x70 [xe] [ ] pf_provision_vf_ggtt+0x7f5/0xa70 [xe] [ ] xe_gt_sriov_pf_config_set_ggtt+0x5e/0x770 [xe] [ ] ggtt_set+0x4b/0x70 [xe] [ ] simple_attr_write_xsigned.constprop.0.isra.0+0xb0/0x110 [ ] ... [drm] GT0: PF: Failed to provision VF1 with 1073741824 (1.00 GiB) GGTT (-ENOSPC) [ ] ... [drm] GT0: PF: VF1 provisioning remains at 0 (0 B) GGTT [ ] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP NOPTI [ ] RIP: 0010:drm_mm_remove_node+0x1b7/0x390 [ ] Call Trace: [ ] <TASK> [ ] ? die_addr+0x2e/0x80 [ ] ? exc_general_protection+0x1a1/0x3e0 [ ] ? asm_exc_general_protection+0x22/0x30 [ ] ? drm_mm_remove_node+0x1b7/0x390 [ ] ggtt_node_remove+0xa5/0xf0 [xe] [ ] xe_ggtt_node_remove+0x35/0x70 [xe] [ ] xe_ttm_bo_destroy+0x123/0x220 [xe] [ ] intel_user_framebuffer_destroy+0x44/0x70 [xe] [ ] intel_plane_destroy_state+0x3b/0xc0 [xe] [ ] drm_atomic_state_default_clear+0x1cd/0x2f0 [ ] intel_atomic_state_clear+0x9/0x20 [xe] [ ] __drm_atomic_state_free+0x1d/0xb0 Fix that by using pf_release_ggtt() on the error path, which now works regardless if the node has GGTT allocation or not. Fixes: 34e804220f69 ("drm/xe: Make xe_ggtt_node struct independent") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241104144901.1903-1-michal.wajdeczko@intel.com (cherry picked from commit 43b1dd2b550f0861ce80fbfffd5881b1b26272b1) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-11-05drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTLMatthew Brost
Upon failure all locks need to be dropped before returning to the user. Fixes: 58480c1c912f ("drm/xe: Skip VMAs pin when requesting signal to the last XE_EXEC") Cc: <stable@vger.kernel.org> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241105043524.4062774-3-matthew.brost@intel.com (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-11-05drm/xe: Fix possible exec queue leak in exec IOCTLMatthew Brost
In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: <stable@vger.kernel.org> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241105043524.4062774-2-matthew.brost@intel.com (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f) Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-11-05Merge tag 'qcom-clk-fixes-for-6.12' of ↵Stephen Boyd
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into clk-fixes Pull Qualcomm clk driver fixes from Bjorn Andersson: - Correct flags for X Elite USB MP GDSC and pcie pipediv2 clocks - Fix alpha PLL post_div mask for the cases where width is not specified - Avoid hangs in the SM8350 video driver (venus) by setting HW_CTRL trigger feature on the video clocks * tag 'qcom-clk-fixes-for-6.12' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: clk: qcom: gcc-x1e80100: Fix USB MP SS1 PHY GDSC pwrsts flags clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks clk: qcom: clk-alpha-pll: Fix pll post div mask when width is not set clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs
2024-11-05selftests/bpf: Use -4095 as the bad address for bits iteratorHou Tao
As reported by Byeonguk, the bad_words test in verifier_bits_iter.c occasionally fails on s390 host. Quoting Ilya's explanation: s390 kernel runs in a completely separate address space, there is no user/kernel split at TASK_SIZE. The same address may be valid in both the kernel and the user address spaces, there is no way to tell by looking at it. The config option related to this property is ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE. Also, unfortunately, 0 is a valid address in the s390 kernel address space. Fix the issue by using -4095 as the bad address for bits iterator, as suggested by Ilya. Verify that bpf_iter_bits_new() returns -EINVAL for NULL address and -EFAULT for bad address. Fixes: ebafc1e535db ("selftests/bpf: Add three test cases for bits_iter") Reported-by: Byeonguk Jeong <jungbu2855@gmail.com> Closes: https://lore.kernel.org/bpf/ZycSXwjH4UTvx-Cn@ub22/ Signed-off-by: Hou Tao <houtao1@huawei.com> Acked-by: Ilya Leoshkevich <iii@linux.ibm.com> Link: https://lore.kernel.org/r/20241105043057.3371482-1-houtao@huaweicloud.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2024-11-05sched_ext: Update scx_show_state.py to match scx_ops_bypass_depth's new typeTejun Heo
0e7ffff1b811 ("scx: Fix raciness in scx_ops_bypass()") converted scx_ops_bypass_depth from an atomic to an int. Update scx_show_state.py accordingly. Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: 0e7ffff1b811 ("scx: Fix raciness in scx_ops_bypass()")
2024-11-05sched_ext: Add a missing newline at the end of an error messageTejun Heo
Signed-off-by: Tejun Heo <tj@kernel.org>
2024-11-05ACPI: allow building without CONFIG_HAS_IOPORTArnd Bergmann
CONFIG_HAS_IOPORT will soon become optional and cause a build time failure when it is disabled but a driver calls inb()/outb(). At the moment, all architectures that can support ACPI have port I/O, but this is not necessarily the case in the future on non-x86 architectures. The result is a set of errors like: drivers/acpi/osl.c: In function 'acpi_os_read_port': include/asm-generic/io.h:542:14: error: call to '_inb' declared with attribute error: inb()) requires CONFIG_HAS_IOPORT Nothing should actually call these functions in this configuration, and if it does, the result would be undefined behavior today, possibly a NULL pointer dereference. Change the low-level functions to return a proper error code when HAS_IOPORT is disabled. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/20241030123701.1538919-2-arnd@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: processor_perflib: extend X86 dependencyArnd Bergmann
The majority of the processor_perflib code is only used by cpufreq drivers on the x86 architecture and makes no sense without the x86 SMI interactions that rely on I/O port access. Replace the existing #ifdef checks with one that covers all of the code that is only used by x86 drivers, saving a little bit of kernel code size on other architectures. There is likely more code under CONFIG_ACPI_PROCESSOR that falls into this category, but changing those would require a larger rework. Suggested-by: Rafael J. Wysocki <rafael@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20241030123701.1538919-1-arnd@kernel.org Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: scan: Use strscpy() instead of strcpy()Muhammad Qasim Abdul Majeed
Replace strcpy() with strscpy() in the ACPI device enumeration code. strcpy() has been deprecated because it is generally unsafe, so it is better to eliminate it from the kernel source. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com> Link: https://patch.msgid.link/20240915183822.34588-9-qasim.majeed20@gmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: SBSHC: Use strscpy() instead of strcpy()Muhammad Qasim Abdul Majeed
Replace strcpy() with strscpy() in the ACPI SBSHC driver. strcpy() has been deprecated because it is generally unsafe, so it is better to eliminate it from the kernel source. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com> Link: https://patch.msgid.link/20240915183822.34588-8-qasim.majeed20@gmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: SBS: Use strscpy() instead of strcpy()Muhammad Qasim Abdul Majeed
Replace strcpy() with strscpy() in the ACPI SBS driver. strcpy() has been deprecated because it is generally unsafe, so it is better to eliminate it from the kernel source. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com> Link: https://patch.msgid.link/20240915183822.34588-7-qasim.majeed20@gmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: power: Use strscpy() instead of strcpy()Muhammad Qasim Abdul Majeed
Replace strcpy() with strscpy() in the ACPI power resource driver. strcpy() has been deprecated because it is generally unsafe, so it is better to eliminate it from the kernel source. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com> Link: https://patch.msgid.link/20240915183822.34588-6-qasim.majeed20@gmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: pci_root: Use strscpy() instead of strcpy()Muhammad Qasim Abdul Majeed
Replace strcpy() with strscpy() in the ACPI pci_root driver. strcpy() has been deprecated because it is generally unsafe, so it is better to eliminate it from the kernel source. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com> Link: https://patch.msgid.link/20240915183822.34588-5-qasim.majeed20@gmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: pci_link: Use strscpy() instead of strcpy()Muhammad Qasim Abdul Majeed
Replace strcpy() with strscpy() in the ACPI pci_link driver. strcpy() has been deprecated because it is generally unsafe, so it is better to eliminate it from the kernel source. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com> Link: https://patch.msgid.link/20240915183822.34588-4-qasim.majeed20@gmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: event: Use strscpy() instead of strcpy()Muhammad Qasim Abdul Majeed
Replace strcpy() with strscpy() in the ACPI event driver. strcpy() has been deprecated because it is generally unsafe, so it is better to eliminate it from the kernel source. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com> Link: https://patch.msgid.link/20240915183822.34588-3-qasim.majeed20@gmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: EC: Use strscpy() instead of strcpy()Muhammad Qasim Abdul Majeed
Replace strcpy() with strscpy() in the ACPI EC driver. strcpy() has been deprecated because it is generally unsafe, so it is better to eliminate it from the kernel source. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com> Link: https://patch.msgid.link/20240915183822.34588-2-qasim.majeed20@gmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: APD: Use strscpy() instead of strcpy()Muhammad Qasim Abdul Majeed
Replace strcpy() with strscpy() in the ACPI APD driver. strcpy() has been deprecated because it is generally unsafe, so it is better to eliminate it from the kernel source. Link: https://github.com/KSPP/linux/issues/88 Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@gmail.com> Link: https://patch.msgid.link/20240915183822.34588-1-qasim.majeed20@gmail.com [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05ACPI: thermal: Use strscpy() instead of strcpy()Abdul Rahim
strcpy() is generally considered unsafe and use of strscpy() is recommended [1]. Also using strscpy() instead of strcpy() makes the following checkpatch warning go away: WARNING: Prefer strscpy over strcpy Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strcpy [1] Signed-off-by: Abdul Rahim <abdul.rahim@myyahoo.com> Link: https://patch.msgid.link/20240913211156.103864-1-abdul.rahim@myyahoo.com [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2024-11-05x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 clientMario Limonciello
A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability. Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Cc: stable@vger.kernel.org Link: https://bugzilla.kernel.org/show_bug.cgi?id=219009
2024-11-05nvme-core: remove repeated wq flagsChaitanya Kulkarni
In nvme_core_init() nvme_wq, nvme_reset_wq, nvme_delete_wq share same flags :- WQ_UNBOUND | WQ_MEM_RECLAIM | WQ_SYSFS. Insated of repeating these flags in each call use the common variable. Signed-off-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2024-11-05nvmet: make nvmet_wq visible in sysfsGuixin Liu
In some complex scenarios, we deploy multiple tasks on a single machine (hybrid deployment), such as Docker containers for function computation (background processing), real-time tasks, monitoring, event handling, and management, along with an NVMe target server. Each of these components is restricted to its own CPU cores to prevent mutual interference and ensure strict isolation. To achieve this level of isolation for nvmet_wq we need to  use sysfs tunables such as cpumask that are currently not accessible. Add WQ_SYSFS flag to alloc_workqueue() when creating nvmet_wq so workqueue tunables are exported in the userspace via sysfs. with this patch :- nvme (nvme-6.13) # ls /sys/devices/virtual/workqueue/nvmet-wq/ affinity_scope  affinity_strict  cpumask  max_active  nice per_cpu power  subsystem  uevent Signed-off-by: Guixin Liu <kanie@linux.alibaba.com> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2024-11-05mm/slab: fix warning caused by duplicate kmem_cache creation in ↵Koichiro Den
kmem_buckets_create Commit b035f5a6d852 ("mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2.405293] __kmem_cache_create_args+0xb8/0x3b0 [ 2.405305] kmem_buckets_create+0xfc/0x320 [ 2.405315] init_msg_buckets+0x34/0x78 [ 2.405326] do_one_initcall+0x64/0x3c8 [ 2.405337] kernel_init_freeable+0x26c/0x578 [ 2.405348] kernel_init+0x3c/0x258 [ 2.405360] ret_from_fork+0x10/0x20 [ 2.405370] ---[ end trace 0000000000000000 ]--- To address this, alias kmem_cache for sizes smaller than min alignment to the aligned sized kmem_cache, as done with the default system kmalloc bucket. Fixes: b32801d1255b ("mm/slab: Introduce kmem_buckets_create() and family") Cc: <stable@vger.kernel.org> # v6.11+ Signed-off-by: Koichiro Den <koichiro.den@gmail.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
2024-11-05ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_removeAmelie Delaunay
In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid. Fixes: 794df9448edb ("ASoC: stm32: spdifrx: manage rebind issue") Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Signed-off-by: Olivier Moysan <olivier.moysan@foss.st.com> Link: https://patch.msgid.link/20241105140242.527279-1-olivier.moysan@foss.st.com Signed-off-by: Mark Brown <broonie@kernel.org>
2024-11-05Merge patch series "Convert ecryptfs to use folios"Christian Brauner
Matthew Wilcox (Oracle) <willy@infradead.org> says: The next step in the folio project is to remove page->index. This patchset does that for ecryptfs. As an unloved filesystem, I haven't made any effort to support large folios; this is just "keep it working". I have only compile tested this, but since it's a straightforward conversion I'm not expecting any problems beyond my fat fingers. * patches from https://lore.kernel.org/r/20241025190822.1319162-1-willy@infradead.org: ecryptfs: Pass the folio index to crypt_extent() ecryptfs: Convert lower_offset_for_page() to take a folio ecryptfs: Convert ecryptfs_decrypt_page() to take a folio ecryptfs: Convert ecryptfs_encrypt_page() to take a folio ecryptfs: Convert ecryptfs_write_lower_page_segment() to take a folio ecryptfs: Convert ecryptfs_write() to use a folio ecryptfs: Convert ecryptfs_read_lower_page_segment() to take a folio ecryptfs: Convert ecryptfs_copy_up_encrypted_with_header() to take a folio ecryptfs: Use a folio throughout ecryptfs_read_folio() ecryptfs: Convert ecryptfs_writepage() to ecryptfs_writepages() Link: https://lore.kernel.org/r/20241025190822.1319162-1-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Pass the folio index to crypt_extent()Matthew Wilcox (Oracle)
We need to pass pages, not folios, to crypt_extent() as we may be working with a plain page rather than a folio. But we need to know the index in the file, so pass it in from the caller. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-11-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Convert lower_offset_for_page() to take a folioMatthew Wilcox (Oracle)
Both callers have a folio, so pass it in and use folio->index instead of page->index. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-10-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Convert ecryptfs_decrypt_page() to take a folioMatthew Wilcox (Oracle)
Both callers have a folio, so pass it in and use it throughout. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-9-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Convert ecryptfs_encrypt_page() to take a folioMatthew Wilcox (Oracle)
All three callers have a folio, so pass it in and use it throughout. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-8-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Convert ecryptfs_write_lower_page_segment() to take a folioMatthew Wilcox (Oracle)
Both callers now have a folio, so pass it in and use it throughout. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-7-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Convert ecryptfs_write() to use a folioMatthew Wilcox (Oracle)
Remove ecryptfs_get_locked_page() and call read_mapping_folio() directly. Use the folio throught this function. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-6-willy@infradead.org Reviewed-by: Pankaj Raghav <p.raghav@samsung.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Convert ecryptfs_read_lower_page_segment() to take a folioMatthew Wilcox (Oracle)
All callers have a folio, so pass it in and use it directly. This will not work for large folios, but I doubt anybody wants to use large folios with ecryptfs. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-5-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Convert ecryptfs_copy_up_encrypted_with_header() to take a folioMatthew Wilcox (Oracle)
Both callers have a folio, so pass it in and use it throughout. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-4-willy@infradead.org Reviewed-by: Pankaj Raghav <p.raghav@samsung.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Use a folio throughout ecryptfs_read_folio()Matthew Wilcox (Oracle)
Remove the conversion to a struct page. Removes a few hidden calls to compound_head(). Use 'err' instead of 'rc' for clarity. Also remove the unnecessary call to ClearPageUptodate(); the uptodate flag is already clear if this function is being called. That lets us switch to folio_end_read() which does one atomic flag operation instead of two. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-3-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05ecryptfs: Convert ecryptfs_writepage() to ecryptfs_writepages()Matthew Wilcox (Oracle)
By adding a ->migrate_folio implementation, theree is no need to keep the ->writepage implementation. The new writepages removes the unnecessary call to SetPageUptodate(); the folio should already be uptodate at this point. Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Link: https://lore.kernel.org/r/20241025190822.1319162-2-willy@infradead.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2024-11-05nvme-pci: use dma_alloc_noncontigous if possibleChristoph Hellwig
Use dma_alloc_noncontigous to allocate a single IOVA-contigous segment when backed by an IOMMU. This allow to easily use bigger segments and avoids running into segment limits if we can avoid it. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2024-11-05nvme-pci: fix freeing of the HMB descriptor tableChristoph Hellwig
The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent. In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page. Fixes: 87ad72a59a38 ("nvme-pci: implement host memory buffer support") Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Keith Busch <kbusch@kernel.org>
2024-11-05drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()Alex Deucher
Avoid a possible buffer overflow if size is larger than 4K. Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434) Cc: stable@vger.kernel.org
2024-11-05drm/amdgpu: Adjust debugfs eviction and IB access permissionsAlex Deucher
Users should not be able to run these. Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 7ba9395430f611cfc101b1c2687732baafa239d5) Cc: stable@vger.kernel.org
2024-11-05drm/amdgpu: Adjust debugfs register access permissionsAlex Deucher
Regular users shouldn't have read access. Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit c0cfd2e652553d607b910be47d0cc5a7f3a78641) Cc: stable@vger.kernel.org
generated by cgit (git 2.34.1) at 2025-09-18 15:23:22 +0000