| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If the process is exiting, the mmput inside mmu notifier callback from
compactd or fork or numa balancing could release the last reference
of mm struct to call exit_mmap and free_pgtable, this triggers deadlock
with below backtrace.
The deadlock will leak kfd process as mmu notifier release is not called
and cause VRAM leaking.
The fix is to take mm reference mmget_non_zero when adding prange to the
deferred list to pair with mmput in deferred list work.
If prange split and add into pchild list, the pchild work_item.mm is not
used, so remove the mm parameter from svm_range_unmap_split and
svm_range_add_child.
The backtrace of hung task:
INFO: task python:348105 blocked for more than 64512 seconds.
Call Trace:
__schedule+0x1c3/0x550
schedule+0x46/0xb0
rwsem_down_write_slowpath+0x24b/0x4c0
unlink_anon_vmas+0xb1/0x1c0
free_pgtables+0xa9/0x130
exit_mmap+0xbc/0x1a0
mmput+0x5a/0x140
svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu]
mn_itree_invalidate+0x72/0xc0
__mmu_notifier_invalidate_range_start+0x48/0x60
try_to_unmap_one+0x10fa/0x1400
rmap_walk_anon+0x196/0x460
try_to_unmap+0xbb/0x210
migrate_page_unmap+0x54d/0x7e0
migrate_pages_batch+0x1c3/0xae0
migrate_pages_sync+0x98/0x240
migrate_pages+0x25c/0x520
compact_zone+0x29d/0x590
compact_zone_order+0xb6/0xf0
try_to_compact_pages+0xbe/0x220
__alloc_pages_direct_compact+0x96/0x1a0
__alloc_pages_slowpath+0x410/0x930
__alloc_pages_nodemask+0x3a9/0x3e0
do_huge_pmd_anonymous_page+0xd7/0x3e0
__handle_mm_fault+0x5e3/0x5f0
handle_mm_fault+0xf7/0x2e0
hmm_vma_fault.isra.0+0x4d/0xa0
walk_pmd_range.isra.0+0xa8/0x310
walk_pud_range+0x167/0x240
walk_pgd_range+0x55/0x100
__walk_page_range+0x87/0x90
walk_page_range+0xf6/0x160
hmm_range_fault+0x4f/0x90
amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu]
amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu]
init_user_pages+0xb1/0x2a0 [amdgpu]
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu]
kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu]
kfd_ioctl+0x29d/0x500 [amdgpu]
Fixes: fa582c6f3684 ("drm/amdkfd: Use mmget_not_zero in MMU notifier")
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)
Cc: stable@vger.kernel.org
|
|
This got missed during SDMA 4.4.4 support.
Fixes: 968e3811c3e8 ("drm/amdgpu: add initial support for sdma444")
Signed-off-by: Kent Russell <kent.russell@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 51526efe02714339ed6139f7bc348377d363200a)
Cc: stable@vger.kernel.org
|
|
Set memory mtype to UC host memory when ext-coherent
flag is set and memory is registered as a SVM allocation.
Reviewed-by: Amber Lin <Amber.Lin@amd.com>
Signed-off-by: David Yat Sin <David.YatSin@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 5d14fdab4778c29cfd39e62c3ce84d232b4a7d8c)
|
|
SDMA 5.x only supports engine soft reset which resets
all queues on the engine. As such, we need to suspend
KFD queues around resets like we do for SDMA 4.x.
Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 61feed0baa1a0d094af0e07e968b1e6e875f07d0)
|
|
While we are indirectly draining our dedicated workqueue ggtt->wq
that we use to complete asynchronous removal of some GGTT nodes,
this happends as part of the managed-drm unwinding (ggtt_fini_early),
which could be later then manage-device unwinding, where we could
already unmap our MMIO/GMS mapping (mmio_fini).
This was recently observed during unsuccessful VF initialization:
[ ] xe 0000:00:02.1: probe with driver xe failed with error -62
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747340 __xe_bo_unpin_map_no_vm (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747540 __xe_bo_unpin_map_no_vm (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747240 __xe_bo_unpin_map_no_vm (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747040 tiles_fini (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e746840 mmio_fini (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e747f40 xe_bo_pinned_fini (16 bytes)
[ ] xe 0000:00:02.1: DEVRES REL ffff88811e746b40 devm_drm_dev_init_release (16 bytes)
[ ] xe 0000:00:02.1: [drm:drm_managed_release] drmres release begin
[ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef81640 __fini_relay (8 bytes)
[ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80d40 guc_ct_fini (8 bytes)
[ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80040 __drmm_mutex_release (8 bytes)
[ ] xe 0000:00:02.1: [drm:drm_managed_release] REL ffff88810ef80140 ggtt_fini_early (8 bytes)
and this was leading to:
[ ] BUG: unable to handle page fault for address: ffffc900058162a0
[ ] #PF: supervisor write access in kernel mode
[ ] #PF: error_code(0x0002) - not-present page
[ ] Oops: Oops: 0002 [#1] SMP NOPTI
[ ] Tainted: [W]=WARN
[ ] Workqueue: xe-ggtt-wq ggtt_node_remove_work_func [xe]
[ ] RIP: 0010:xe_ggtt_set_pte+0x6d/0x350 [xe]
[ ] Call Trace:
[ ] <TASK>
[ ] xe_ggtt_clear+0xb0/0x270 [xe]
[ ] ggtt_node_remove+0xbb/0x120 [xe]
[ ] ggtt_node_remove_work_func+0x30/0x50 [xe]
[ ] process_one_work+0x22b/0x6f0
[ ] worker_thread+0x1e8/0x3d
Add managed-device action that will explicitly drain the workqueue
with all pending node removals prior to releasing MMIO/GSM mapping.
Fixes: 919bb54e989c ("drm/xe: Fix missing runtime outer protection for ggtt_remove_node")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/20250612220937.857-2-michal.wajdeczko@intel.com
(cherry picked from commit 89d2835c3680ab1938e22ad81b1c9f8c686bd391)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
|
During driver probe we might be briefly using CT safe mode, which
is based on a delayed work, but usually we are able to stop this
once we have IRQ fully operational. However, if we abort the probe
quite early then during unwind we might try to destroy the workqueue
while there is still a pending delayed work that attempts to restart
itself which triggers a WARN.
This was recently observed during unsuccessful VF initialization:
[ ] xe 0000:00:02.1: probe with driver xe failed with error -62
[ ] ------------[ cut here ]------------
[ ] workqueue: cannot queue safe_mode_worker_func [xe] on wq xe-g2h-wq
[ ] WARNING: CPU: 9 PID: 0 at kernel/workqueue.c:2257 __queue_work+0x287/0x710
[ ] RIP: 0010:__queue_work+0x287/0x710
[ ] Call Trace:
[ ] delayed_work_timer_fn+0x19/0x30
[ ] call_timer_fn+0xa1/0x2a0
Exit the CT safe mode on unwind to avoid that warning.
Fixes: 09b286950f29 ("drm/xe/guc: Allow CTB G2H processing without G2H IRQ")
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Link: https://lore.kernel.org/r/20250612220937.857-3-michal.wajdeczko@intel.com
(cherry picked from commit 2ddbb73ec20b98e70a5200cb85deade22ccea2ec)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
|
Only need the flush for DPT host updates here. Normal GGTT updates don't
need special flush.
Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340")
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: stable@vger.kernel.org # v6.12+
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20250606104546.1996818-4-matthew.auld@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 35db1da40c8cfd7511dc42f342a133601eb45449)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
|
Flushing l2 is only needed after all data has been written.
Fixes: 01570b446939 ("drm/xe/bmg: implement Wa_16023588340")
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: stable@vger.kernel.org # v6.12+
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://lore.kernel.org/r/20250606104546.1996818-3-matthew.auld@intel.com
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
(cherry picked from commit 0dd2dd0182bc444a62652e89d08c7f0e4fde15ba)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
|
By default, HPD was disabled on SN65DSI86 bridge. When the driver was
added (commit "a095f15c00e27"), the HPD_DISABLE bit was set in pre-enable
call which was moved to other function calls subsequently.
Later on, commit "c312b0df3b13" added detect utility for DP mode. But with
HPD_DISABLE bit set, all the HPD events are disabled[0] and the debounced
state always return 1 (always connected state).
Set HPD_DISABLE bit conditionally based on display sink's connector type.
Since the HPD_STATE is reflected correctly only after waiting for debounce
time (~100-400ms) and adding this delay in detect() is not feasible
owing to the performace impact (glitches and frame drop), remove runtime
calls in detect() and add hpd_enable()/disable() bridge hooks with runtime
calls, to detect hpd properly without any delay.
[0]: <https://www.ti.com/lit/gpn/SN65DSI86> (Pg. 32)
Fixes: c312b0df3b13 ("drm/bridge: ti-sn65dsi86: Implement bridge connector operations for DP")
Cc: Max Krummenacher <max.krummenacher@toradex.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20250624044835.165708-1-j-choudhary@ti.com
|
|
An earlier patch fixed a build failure with clang, but I still see the
same problem with some configurations using gcc:
drivers/gpu/drm/i915/i915_pmu.c: In function 'config_mask':
include/linux/compiler_types.h:568:38: error: call to '__compiletime_assert_462' declared with attribute error: BUILD_BUG_ON failed: bit > BITS_PER_TYPE(typeof_member(struct i915_pmu, enable)) - 1
drivers/gpu/drm/i915/i915_pmu.c:116:3: note: in expansion of macro 'BUILD_BUG_ON'
116 | BUILD_BUG_ON(bit >
As I understand it, the problem is that the function is not always fully
inlined, but the __builtin_constant_p() can still evaluate the argument
as being constant.
Marking it as __always_inline so far works for me in all configurations.
Fixes: a7137b1825b5 ("drm/i915/pmu: Fix build error with GCOV and AutoFDO enabled")
Fixes: a644fde77ff7 ("drm/i915/pmu: Change bitmask of enabled events to u32")
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250620111824.3395007-1-arnd@kernel.org
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit ef69f9dd1cd7301cdf04ba326ed28152a3affcf6)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
Prevent other bits of mailbox power limit from being overwritten with 0.
This issue was due to a missing read and modify of current power limit,
before setting a requested mailbox power limit, which is added in this
patch.
v2:
- Improve commit message. (Anshuman)
v3:
- Rebase.
- Rephrase commit message. (Riana)
- Add read-modify-write variant of xe_hwmon_pcode_write_power_limit()
i.e. xe_hwmon_pcode_rmw_power_limit(). (Badal)
- Use xe_hwmon_pcode_rmw_power_limit() to set mailbox power limits.
- Remove xe_hwmon_pcode_write_power_limit() as all mailbox power limits
writes use xe_hwmon_pcode_rmw_power_limit() only.
v4:
- Use PWR_LIM in place of (PWR_LIM_EN | PWR_LIM_VAL) wherever
applicable. (Riana)
Fixes: 25a2aa779fc3 ("drm/xe/hwmon: Add support to manage power limits though mailbox")
Reviewed-by: Riana Tauro <riana.tauro@intel.com>
Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
Reviewed-by: Badal Nilawar <badal.nilawar@intel.com>
Link: https://lore.kernel.org/r/20250617120030.612819-1-karthik.poosa@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
(cherry picked from commit 8aa7306631f088881759398972d503757cf0c901)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
|
Add check for the return value of alloc_ordered_workqueue()
in xe_display_create() to catch potential exception.
Fixes: 44e694958b95 ("drm/xe/display: Implement display support")
Cc: stable@vger.kernel.org
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://lore.kernel.org/r/4ee1b0e5d1626ce1dde2e82af05c2edaed50c3aa.1747397638.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 5b62d63395d5b7d4094e7cd380bccae4b25415cb)
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
|
|
When EDID is retrieved via drm_edid_raw(), it doesn't guarantee to
return proper EDID bytes the caller wants: it may be either NULL (that
leads to an Oops) or with too long bytes over the fixed size raw_edid
array (that may lead to memory corruption). The latter was reported
actually when connected with a bad adapter.
Add sanity checks for drm_edid_raw() to address the above corner
cases, and return EDID_BAD_INPUT accordingly.
Fixes: 48edb2a4256e ("drm/amd/display: switch amdgpu_dm_connector to use struct drm_edid")
Link: https://bugzilla.suse.com/show_bug.cgi?id=1236415
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 648d3f4d209725d51900d6a3ed46b7b600140cdf)
Cc: stable@vger.kernel.org
|
|
[Why]
commit 16dc8bc27c2a ("drm/amd/display: Export full brightness range to
userspace") adjusted the brightness range to scale to larger values, but
missed updating AMDGPU_MAX_BL_LEVEL which is needed to make sure that
scaling works properly with custom brightness curves.
[How]
As the change for max brightness of 0xFFFF only applies to devices
supporting DC, use existing DC define MAX_BACKLIGHT_LEVEL.
Fixes: 16dc8bc27c2a ("drm/amd/display: Export full brightness range to userspace")
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/r/20250623171114.1156451-1-mario.limonciello@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 5b852044eb0d3e1f1c946d32e05fcb068e0a20a0)
Cc: stable@vger.kernel.org
|
|
SDMA 7.0.0/1: 7836028
Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 8c011408ed842dfccdd50a90a9cf6bccdb85cc0e)
|
|
SDMA 6.0.0 version 24
SDMA 6.0.2 version 21
SDMA 6.0.3 version 25
Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit e8cca30d8b34f1c4101c237914c53068d4a55e73)
|
|
commit 017fbb6690c2 ("drm/amdgpu/discovery: check ip_discovery fw file
available") added support for reading an amdgpu IP discovery bin file
for some specific products. If it's not found then it will fallback to
hardcoded values. However if it's not found there is also a lot of noise
about missing files and errors.
Adjust the error handling to decrease most messages to DEBUG and to show
users less about missing files.
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Reported-by: Marcus Seyfarth <m.seyfarth@gmail.com>
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4312
Tested-by: Marcus Seyfarth <m.seyfarth@gmail.com>
Fixes: 017fbb6690c2 ("drm/amdgpu/discovery: check ip_discovery fw file available")
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://lore.kernel.org/r/20250617183052.1692059-1-superm1@kernel.org
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 49f1f9f6c3c9febf8ba93f94a8d9c8d03e1ea0a1)
|
|
Seems some older MES firmware versions do not properly support
this packet. Add back some the compatibility checks.
v2: switch to fw version check (Shaoyun)
Fixes: f81cd793119e ("drm/amd/amdgpu: Fix MES init sequence")
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4295
Cc: Shaoyun Liu <shaoyun.liu@amd.com>
Reviewed-by: shaoyun.liu <shaoyun.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 0180e0a5dd5c6ff118043ee42dbbbddaf881f283)
Cc: stable@vger.kernel.org
|
|
Enable the cleaner shader for other GFX9.x series of GPUs to provide
data isolation between GPU workloads. The cleaner shader is responsible
for clearing the Local Data Store (LDS), Vector General Purpose
Registers (VGPRs), and Scalar General Purpose Registers (SGPRs), which
helps prevent data leakage and ensures accurate computation results.
This update extends cleaner shader support to GFX9.x GPUs, previously
available for GFX9.4.2. It enhances security by clearing GPU memory
between processes and maintains a consistent GPU state across KGD and
KFD workloads.
Cc: Manu Rastogi <manu.rastogi@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 99808926d0ea6234a89e35240a7cb088368de9e1)
|
|
The bridge used in drm_connector_hdmi_audio_init() does not correctly
point to the required audio bridge, which lead to incorrect audio
configuration input.
Fixes: 231adeda9f67 ("drm/bridge-connector: hook DisplayPort audio support")
Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Link: https://lore.kernel.org/r/20250620011616.118-1-kernel@airkyi.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
|
|
Reading DPCD registers has side-effects in general. In particular
accessing registers outside of the link training register range
(0x102-0x106, 0x202-0x207, 0x200c-0x200f, 0x2216) is explicitly
forbidden by the DP v2.1 Standard, see
3.6.5.1 DPTX AUX Transaction Handling Mandates
3.6.7.4 128b/132b DP Link Layer LTTPR Link Training Mandates
Based on my tests, accessing the DPCD_REV register during the link
training of an UHBR TBT DP tunnel sink leads to link training failures.
Solve the above by using the DP_LANE0_1_STATUS (0x202) register for the
DPCD register access quirk.
Cc: <stable@vger.kernel.org>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://lore.kernel.org/r/20250605082850.65136-2-imre.deak@intel.com
(cherry picked from commit a40c5d727b8111b5db424a1e43e14a1dcce1e77f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
DIV_ROUND_CLOSEST_ULL uses do_div(), which expects a 32-bit divisor.
When passing a 64-bit constant like CURVE2_MULTIPLIER, the value is
silently truncated to u32, potentially leading to incorrect results
on large divisors.
Replace DIV_ROUND_CLOSEST_ULL with DIV64_U64_ROUND_CLOSEST which correctly
handles full 64-bit division.
v2: Use DIV64_U64_ROUND_CLOSEST instead of div64_u64 macro. (Jani)
Fixes: 5947642004bf ("drm/i915/display: Add support for SNPS PHY HDMI PLL algorithm for DG2")
Reported-by: Vas Novikov <vasya.novikov@gmail.com>
Closes: https://lore.kernel.org/all/8d7c7958-9558-4c8a-a81a-e9310f2d8852@gmail.com/
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Vas Novikov <vasya.novikov@gmail.com>
Cc: stable@vger.kernel.org # v6.15+
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://lore.kernel.org/r/20250618130951.1596587-2-ankit.k.nautiyal@intel.com
(cherry picked from commit b300a175a11e6a934d728317dc39787723cc7917)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
|
|
The drm_writeback_connector_cleanup have the signature:
static void drm_writeback_connector_cleanup(
struct drm_device *dev,
struct drm_writeback_connector *wb_connector)
But it is stored and used as a drmres_release_t
typedef void (*drmres_release_t)(struct drm_device *dev, void *res);
While the current code is valid and does not produce any warning, the
CFI runtime check (CONFIG_CFI_CLANG) can fail because the function
signature is not the same as drmres_release_t.
In order to fix this, change the function signature to match what is
expected by drmres_release_t.
Fixes: 1914ba2b91ea ("drm: writeback: Create drmm variants for drm_writeback_connector initialization")
Suggested-by: Mark Yacoub <markyacoub@google.com>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://lore.kernel.org/r/20250429-drm-fix-writeback-cleanup-v2-1-548ff3a4e284@bootlin.com
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
|
|
|
|
If spacemit_i2c_xfer_msg() times out waiting for a message transfer to
complete, or if the hardware reports an error, it returns a negative
error code (-ETIMEDOUT, -EAGAIN, -ENXIO. or -EIO).
The sole caller of spacemit_i2c_xfer_msg() is spacemit_i2c_xfer(),
which is the i2c_algorithm->xfer callback function. It currently
does not save the value returned by spacemit_i2c_xfer_msg().
The result is that transfer errors go unreported, and a caller
has no indication anything is wrong.
When this code was out for review, the return value *was* checked
in early versions. But for some reason, that assignment got dropped
between versions 5 and 6 of the series, perhaps related to reworking
the code to merge spacemit_i2c_xfer_core() into spacemit_i2c_xfer().
Simply assigning the value returned to "ret" fixes the problem.
Fixes: 5ea558473fa31 ("i2c: spacemit: add support for SpacemiT K1 SoC")
Signed-off-by: Alex Elder <elder@riscstar.com>
Cc: <stable@vger.kernel.org> # v6.15+
Reviewed-by: Troy Mitchell <troymitchell988@gmail.com>
Link: https://lore.kernel.org/r/20250616125137.1555453-1-elder@riscstar.com
Signed-off-by: Andi Shyti <andi@smida.it>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
|
|
Replaced hardcoded value 16 with SMB2_NTLMV2_SESSKEY_SIZE
in the auth_key definition and memcpy call.
Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Signed-off-by: Bharath SM <bharathsm@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
Replaced hardcoded length with sizeof(flags_string).
Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Signed-off-by: Bharath SM <bharathsm@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
Change the pos field in struct cached_dirents from int to loff_t
to support large directory offsets. This avoids overflow and
matches kernel conventions for directory positions.
Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Signed-off-by: Bharath SM <bharathsm@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
Under low-memory conditions, close_all_cached_dirs() can't move the
dentries to a separate list to dput() them once the locks are dropped.
This will result in a "Dentry still in use" error, so add an error
message that makes it clear this is what happened:
[ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries
[ 495.281595] ------------[ cut here ]------------
[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs]
[ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0
Also, bail out of looping through all tcons as soon as a single
allocation fails, since we're already in trouble, and kmalloc() attempts
for subseqeuent tcons are likely to fail just like the first one did.
Signed-off-by: Paul Aurich <paul@darkrain42.org>
Acked-by: Bharath SM <bharathsm@microsoft.com>
Suggested-by: Ruben Devos <rdevos@oxya.com>
Cc: stable@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
Fix cifs_prepare_write() to negotiate the wsize if it is unset.
Reviewed-by: Shyam Prasad N <nspmangalore@gmail.com>
Reviewed-by: Bharath SM <bharathsm@microsoft.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Paulo Alcantara <pc@manguebit.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
cc: linux-cifs@vger.kernel.org
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
This fixes the following problem:
[ 749.901015] [ T8673] run fstests cifs/001 at 2025-06-17 09:40:30
[ 750.346409] [ T9870] ==================================================================
[ 750.346814] [ T9870] BUG: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.347330] [ T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870
[ 750.347705] [ T9870]
[ 750.348077] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Not tainted 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary)
[ 750.348082] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 750.348085] [ T9870] Call Trace:
[ 750.348086] [ T9870] <TASK>
[ 750.348088] [ T9870] dump_stack_lvl+0x76/0xa0
[ 750.348106] [ T9870] print_report+0xd1/0x640
[ 750.348116] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 750.348120] [ T9870] ? kasan_complete_mode_report_info+0x26/0x210
[ 750.348124] [ T9870] kasan_report+0xe7/0x130
[ 750.348128] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.348262] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.348377] [ T9870] __asan_report_store8_noabort+0x17/0x30
[ 750.348381] [ T9870] smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.348496] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs]
[ 750.348625] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs]
[ 750.348741] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.348749] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.348870] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.348990] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.348995] [ T9870] smbd_send+0x58c/0x9c0 [cifs]
[ 750.349117] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs]
[ 750.349231] [ T9870] ? unwind_get_return_address+0x65/0xb0
[ 750.349235] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10
[ 750.349242] [ T9870] ? arch_stack_walk+0xa7/0x100
[ 750.349250] [ T9870] ? stack_trace_save+0x92/0xd0
[ 750.349254] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs]
[ 750.349374] [ T9870] ? kernel_text_address+0x173/0x190
[ 750.349379] [ T9870] ? kasan_save_stack+0x39/0x70
[ 750.349382] [ T9870] ? kasan_save_track+0x18/0x70
[ 750.349385] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0
[ 750.349389] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs]
[ 750.349508] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs]
[ 750.349626] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs]
[ 750.349746] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]
[ 750.349867] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.349900] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.349929] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.349958] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.349987] [ T9870] ? do_writepages+0x21f/0x590
[ 750.349993] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140
[ 750.349997] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.350002] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs]
[ 750.350131] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs]
[ 750.350255] [ T9870] ? local_clock_noinstr+0xe/0xd0
[ 750.350261] [ T9870] ? kasan_save_alloc_info+0x37/0x60
[ 750.350268] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.350271] [ T9870] ? _raw_spin_lock+0x81/0xf0
[ 750.350275] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.350278] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs]
[ 750.350398] [ T9870] cifs_call_async+0x477/0xb00 [cifs]
[ 750.350518] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
[ 750.350636] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs]
[ 750.350756] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.350760] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.350763] [ T9870] ? __smb2_plain_req_init+0x933/0x1090 [cifs]
[ 750.350891] [ T9870] smb2_async_writev+0x15ff/0x2460 [cifs]
[ 750.351008] [ T9870] ? sched_clock_noinstr+0x9/0x10
[ 750.351012] [ T9870] ? local_clock_noinstr+0xe/0xd0
[ 750.351018] [ T9870] ? __pfx_smb2_async_writev+0x10/0x10 [cifs]
[ 750.351144] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 750.351150] [ T9870] ? _raw_spin_unlock+0xe/0x40
[ 750.351154] [ T9870] ? cifs_pick_channel+0x242/0x370 [cifs]
[ 750.351275] [ T9870] cifs_issue_write+0x256/0x610 [cifs]
[ 750.351554] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]
[ 750.351677] [ T9870] netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.351710] [ T9870] netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.351740] [ T9870] ? rolling_buffer_append+0x12d/0x440 [netfs]
[ 750.351769] [ T9870] netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.351798] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.351804] [ T9870] netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.351835] [ T9870] ? __pfx_netfs_writepages+0x10/0x10 [netfs]
[ 750.351864] [ T9870] ? exit_files+0xab/0xe0
[ 750.351867] [ T9870] ? do_exit+0x148f/0x2980
[ 750.351871] [ T9870] ? do_group_exit+0xb5/0x250
[ 750.351874] [ T9870] ? arch_do_signal_or_restart+0x92/0x630
[ 750.351879] [ T9870] ? exit_to_user_mode_loop+0x98/0x170
[ 750.351882] [ T9870] ? do_syscall_64+0x2cf/0xd80
[ 750.351886] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.351890] [ T9870] do_writepages+0x21f/0x590
[ 750.351894] [ T9870] ? __pfx_do_writepages+0x10/0x10
[ 750.351897] [ T9870] filemap_fdatawrite_wbc+0xe1/0x140
[ 750.351901] [ T9870] __filemap_fdatawrite_range+0xba/0x100
[ 750.351904] [ T9870] ? __pfx___filemap_fdatawrite_range+0x10/0x10
[ 750.351912] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.351916] [ T9870] filemap_write_and_wait_range+0x7d/0xf0
[ 750.351920] [ T9870] cifs_flush+0x153/0x320 [cifs]
[ 750.352042] [ T9870] filp_flush+0x107/0x1a0
[ 750.352046] [ T9870] filp_close+0x14/0x30
[ 750.352049] [ T9870] put_files_struct.part.0+0x126/0x2a0
[ 750.352053] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.352058] [ T9870] exit_files+0xab/0xe0
[ 750.352061] [ T9870] do_exit+0x148f/0x2980
[ 750.352065] [ T9870] ? __pfx_do_exit+0x10/0x10
[ 750.352069] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.352072] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0
[ 750.352076] [ T9870] do_group_exit+0xb5/0x250
[ 750.352080] [ T9870] get_signal+0x22d3/0x22e0
[ 750.352086] [ T9870] ? __pfx_get_signal+0x10/0x10
[ 750.352089] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100
[ 750.352101] [ T9870] ? folio_add_lru+0xda/0x120
[ 750.352105] [ T9870] arch_do_signal_or_restart+0x92/0x630
[ 750.352109] [ T9870] ? __pfx_arch_do_signal_or_restart+0x10/0x10
[ 750.352115] [ T9870] exit_to_user_mode_loop+0x98/0x170
[ 750.352118] [ T9870] do_syscall_64+0x2cf/0xd80
[ 750.352123] [ T9870] ? __kasan_check_read+0x11/0x20
[ 750.352126] [ T9870] ? count_memcg_events+0x1b4/0x420
[ 750.352132] [ T9870] ? handle_mm_fault+0x148/0x690
[ 750.352136] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0
[ 750.352140] [ T9870] ? __kasan_check_read+0x11/0x20
[ 750.352143] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100
[ 750.352146] [ T9870] ? irqentry_exit_to_user_mode+0x2e/0x250
[ 750.352151] [ T9870] ? irqentry_exit+0x43/0x50
[ 750.352154] [ T9870] ? exc_page_fault+0x75/0xe0
[ 750.352160] [ T9870] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.352163] [ T9870] RIP: 0033:0x7858c94ab6e2
[ 750.352167] [ T9870] Code: Unable to access opcode bytes at 0x7858c94ab6b8.
[ 750.352175] [ T9870] RSP: 002b:00007858c9248ce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000022
[ 750.352179] [ T9870] RAX: fffffffffffffdfe RBX: 00007858c92496c0 RCX: 00007858c94ab6e2
[ 750.352182] [ T9870] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 750.352184] [ T9870] RBP: 00007858c9248d10 R08: 0000000000000000 R09: 0000000000000000
[ 750.352185] [ T9870] R10: 0000000000000000 R11: 0000000000000246 R12: fffffffffffffde0
[ 750.352187] [ T9870] R13: 0000000000000020 R14: 0000000000000002 R15: 00007ffc072d2230
[ 750.352191] [ T9870] </TASK>
[ 750.352195] [ T9870]
[ 750.395206] [ T9870] Allocated by task 9870 on cpu 0 at 750.346406s:
[ 750.395523] [ T9870] kasan_save_stack+0x39/0x70
[ 750.395532] [ T9870] kasan_save_track+0x18/0x70
[ 750.395536] [ T9870] kasan_save_alloc_info+0x37/0x60
[ 750.395539] [ T9870] __kasan_slab_alloc+0x9d/0xa0
[ 750.395543] [ T9870] kmem_cache_alloc_noprof+0x13c/0x3f0
[ 750.395548] [ T9870] mempool_alloc_slab+0x15/0x20
[ 750.395553] [ T9870] mempool_alloc_noprof+0x135/0x340
[ 750.395557] [ T9870] smbd_post_send_iter+0x63e/0x3070 [cifs]
[ 750.395694] [ T9870] smbd_send+0x58c/0x9c0 [cifs]
[ 750.395819] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs]
[ 750.395950] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs]
[ 750.396081] [ T9870] cifs_call_async+0x477/0xb00 [cifs]
[ 750.396232] [ T9870] smb2_async_writev+0x15ff/0x2460 [cifs]
[ 750.396359] [ T9870] cifs_issue_write+0x256/0x610 [cifs]
[ 750.396492] [ T9870] netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.396544] [ T9870] netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.396576] [ T9870] netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.396608] [ T9870] netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.396639] [ T9870] do_writepages+0x21f/0x590
[ 750.396643] [ T9870] filemap_fdatawrite_wbc+0xe1/0x140
[ 750.396647] [ T9870] __filemap_fdatawrite_range+0xba/0x100
[ 750.396651] [ T9870] filemap_write_and_wait_range+0x7d/0xf0
[ 750.396656] [ T9870] cifs_flush+0x153/0x320 [cifs]
[ 750.396787] [ T9870] filp_flush+0x107/0x1a0
[ 750.396791] [ T9870] filp_close+0x14/0x30
[ 750.396795] [ T9870] put_files_struct.part.0+0x126/0x2a0
[ 750.396800] [ T9870] exit_files+0xab/0xe0
[ 750.396803] [ T9870] do_exit+0x148f/0x2980
[ 750.396808] [ T9870] do_group_exit+0xb5/0x250
[ 750.396813] [ T9870] get_signal+0x22d3/0x22e0
[ 750.396817] [ T9870] arch_do_signal_or_restart+0x92/0x630
[ 750.396822] [ T9870] exit_to_user_mode_loop+0x98/0x170
[ 750.396827] [ T9870] do_syscall_64+0x2cf/0xd80
[ 750.396832] [ T9870] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.396836] [ T9870]
[ 750.397150] [ T9870] The buggy address belongs to the object at ffff888011082800
which belongs to the cache smbd_request_0000000008f3bd7b of size 144
[ 750.397798] [ T9870] The buggy address is located 0 bytes to the right of
allocated 144-byte region [ffff888011082800, ffff888011082890)
[ 750.398469] [ T9870]
[ 750.398800] [ T9870] The buggy address belongs to the physical page:
[ 750.399141] [ T9870] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11082
[ 750.399148] [ T9870] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)
[ 750.399155] [ T9870] page_type: f5(slab)
[ 750.399161] [ T9870] raw: 000fffffc0000000 ffff888022d65640 dead000000000122 0000000000000000
[ 750.399165] [ T9870] raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000
[ 750.399169] [ T9870] page dumped because: kasan: bad access detected
[ 750.399172] [ T9870]
[ 750.399505] [ T9870] Memory state around the buggy address:
[ 750.399863] [ T9870] ffff888011082780: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 750.400247] [ T9870] ffff888011082800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 750.400618] [ T9870] >ffff888011082880: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 750.400982] [ T9870] ^
[ 750.401370] [ T9870] ffff888011082900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 750.401774] [ T9870] ffff888011082980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 750.402171] [ T9870] ==================================================================
[ 750.402696] [ T9870] Disabling lock debugging due to kernel taint
[ 750.403202] [ T9870] BUG: unable to handle page fault for address: ffff8880110a2000
[ 750.403797] [ T9870] #PF: supervisor write access in kernel mode
[ 750.404204] [ T9870] #PF: error_code(0x0003) - permissions violation
[ 750.404581] [ T9870] PGD 5ce01067 P4D 5ce01067 PUD 5ce02067 PMD 78aa063 PTE 80000000110a2021
[ 750.404969] [ T9870] Oops: Oops: 0003 [#1] SMP KASAN PTI
[ 750.405394] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Tainted: G B 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary)
[ 750.406510] [ T9870] Tainted: [B]=BAD_PAGE
[ 750.406967] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 750.407440] [ T9870] RIP: 0010:smb_set_sge+0x15c/0x3b0 [cifs]
[ 750.408065] [ T9870] Code: 48 83 f8 ff 0f 84 b0 00 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 e1 48 c1 e9 03 80 3c 11 00 0f 85 69 01 00 00 49 8d 7c 24 08 <49> 89 04 24 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f
[ 750.409283] [ T9870] RSP: 0018:ffffc90005e2e758 EFLAGS: 00010246
[ 750.409803] [ T9870] RAX: ffff888036c53400 RBX: ffffc90005e2e878 RCX: 1ffff11002214400
[ 750.410323] [ T9870] RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff8880110a2008
[ 750.411217] [ T9870] RBP: ffffc90005e2e798 R08: 0000000000000001 R09: 0000000000000400
[ 750.411770] [ T9870] R10: ffff888011082800 R11: 0000000000000000 R12: ffff8880110a2000
[ 750.412325] [ T9870] R13: 0000000000000000 R14: ffffc90005e2e888 R15: ffff88801a4b6000
[ 750.412901] [ T9870] FS: 0000000000000000(0000) GS:ffff88812bc68000(0000) knlGS:0000000000000000
[ 750.413477] [ T9870] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 750.414077] [ T9870] CR2: ffff8880110a2000 CR3: 000000005b0a6005 CR4: 00000000000726f0
[ 750.414654] [ T9870] Call Trace:
[ 750.415211] [ T9870] <TASK>
[ 750.415748] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs]
[ 750.416449] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs]
[ 750.417128] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.417685] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.418380] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.419055] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.419624] [ T9870] smbd_send+0x58c/0x9c0 [cifs]
[ 750.420297] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs]
[ 750.420936] [ T9870] ? unwind_get_return_address+0x65/0xb0
[ 750.421456] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10
[ 750.421954] [ T9870] ? arch_stack_walk+0xa7/0x100
[ 750.422460] [ T9870] ? stack_trace_save+0x92/0xd0
[ 750.422948] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs]
[ 750.423579] [ T9870] ? kernel_text_address+0x173/0x190
[ 750.424056] [ T9870] ? kasan_save_stack+0x39/0x70
[ 750.424813] [ T9870] ? kasan_save_track+0x18/0x70
[ 750.425323] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0
[ 750.425831] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs]
[ 750.426548] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs]
[ 750.427231] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs]
[ 750.427882] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]
[ 750.428909] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.429425] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.429882] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.430345] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.430809] [ T9870] ? do_writepages+0x21f/0x590
[ 750.431239] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140
[ 750.431652] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.432041] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs]
[ 750.432586] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs]
[ 750.433108] [ T9870] ? local_clock_noinstr+0xe/0xd0
[ 750.433482] [ T9870] ? kasan_save_alloc_info+0x37/0x60
[ 750.433855] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.434214] [ T9870] ? _raw_spin_lock+0x81/0xf0
[ 750.434561] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.434903] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs]
[ 750.435394] [ T9870] cifs_call_async+0x477/0xb00 [cifs]
[ 750.435892] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
[ 750.436388] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs]
[ 750.436881] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.437237] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.437579] [ T9870] ? __smb2_plain_req_init+0x933/0x1090 [cifs]
[ 750.438062] [ T9870] smb2_async_writev+0x15ff/0x2460 [cifs]
[ 750.438557] [ T9870] ? sched_clock_noinstr+0x9/0x10
[ 750.438906] [ T9870] ? local_clock_noinstr+0xe/0xd0
[ 750.439293] [ T9870] ? __pfx_smb2_async_writev+0x10/0x10 [cifs]
[ 750.439786] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 750.440143] [ T9870] ? _raw_spin_unlock+0xe/0x40
[ 750.440495] [ T9870] ? cifs_pick_channel+0x242/0x370 [cifs]
[ 750.440989] [ T9870] cifs_issue_write+0x256/0x610 [cifs]
[ 750.441492] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]
[ 750.441987] [ T9870] netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.442387] [ T9870] netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.442969] [ T9870] ? rolling_buffer_append+0x12d/0x440 [netfs]
[ 750.443376] [ T9870] netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.443768] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.444145] [ T9870] netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.444541] [ T9870] ? __pfx_netfs_writepages+0x10/0x10 [netfs]
[ 750.444936] [ T9870] ? exit_files+0xab/0xe0
[ 750.445312] [ T9870] ? do_exit+0x148f/0x2980
[ 750.445672] [ T9870] ? do_group_exit+0xb5/0x250
[ 750.446028] [ T9870] ? arch_do_signal_or_restart+0x92/0x630
[ 750.446402] [ T9870] ? exit_to_user_mode_loop+0x98/0x170
[ 750.446762] [ T9870] ? do_syscall_64+0x2cf/0xd80
[ 750.447132] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.447499] [ T9870] do_writepages+0x21f/0x590
[ 750.447859] [ T9870] ? __pfx_do_writepages+0x10/0x10
[ 750.448236] [ T9870] filemap_fdatawrite_wbc+0xe1/0x140
[ 750.448595] [ T9870] __filemap_fdatawrite_range+0xba/0x100
[ 750.448953] [ T9870] ? __pfx___filemap_fdatawrite_range+0x10/0x10
[ 750.449336] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.449697] [ T9870] filemap_write_and_wait_range+0x7d/0xf0
[ 750.450062] [ T9870] cifs_flush+0x153/0x320 [cifs]
[ 750.450592] [ T9870] filp_flush+0x107/0x1a0
[ 750.450952] [ T9870] filp_close+0x14/0x30
[ 750.451322] [ T9870] put_files_struct.part.0+0x126/0x2a0
[ 750.451678] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.452033] [ T9870] exit_files+0xab/0xe0
[ 750.452401] [ T9870] do_exit+0x148f/0x2980
[ 750.452751] [ T9870] ? __pfx_do_exit+0x10/0x10
[ 750.453109] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.453459] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0
[ 750.453787] [ T9870] do_group_exit+0xb5/0x250
[ 750.454082] [ T9870] get_signal+0x22d3/0x22e0
[ 750.454406] [ T9870] ? __pfx_get_signal+0x10/0x10
[ 750.454709] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100
[ 750.455031] [ T9870] ? folio_add_lru+0xda/0x120
[ 750.455347] [ T9870] arch_do_signal_or_restart+0x92/0x630
[ 750.455656] [ T9870] ? __pfx_arch_do_signal_or_restart+0x10/0x10
[ 750.455967] [ T9870] exit_to_user_mode_loop+0x98/0x170
[ 750.456282] [ T9870] do_syscall_64+0x2cf/0xd80
[ 750.456591] [ T9870] ? __kasan_check_read+0x11/0x20
[ 750.456897] [ T9870] ? count_memcg_events+0x1b4/0x420
[ 750.457280] [ T9870] ? handle_mm_fault+0x148/0x690
[ 750.457616] [ T9870] ? _raw_spin_lock_irq+0x8a/0xf0
[ 750.457925] [ T9870] ? __kasan_check_read+0x11/0x20
[ 750.458297] [ T9870] ? fpregs_assert_state_consistent+0x68/0x100
[ 750.458672] [ T9870] ? irqentry_exit_to_user_mode+0x2e/0x250
[ 750.459191] [ T9870] ? irqentry_exit+0x43/0x50
[ 750.459600] [ T9870] ? exc_page_fault+0x75/0xe0
[ 750.460130] [ T9870] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.460570] [ T9870] RIP: 0033:0x7858c94ab6e2
[ 750.461206] [ T9870] Code: Unable to access opcode bytes at 0x7858c94ab6b8.
[ 750.461780] [ T9870] RSP: 002b:00007858c9248ce8 EFLAGS: 00000246 ORIG_RAX: 0000000000000022
[ 750.462327] [ T9870] RAX: fffffffffffffdfe RBX: 00007858c92496c0 RCX: 00007858c94ab6e2
[ 750.462653] [ T9870] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 750.462969] [ T9870] RBP: 00007858c9248d10 R08: 0000000000000000 R09: 0000000000000000
[ 750.463290] [ T9870] R10: 0000000000000000 R11: 0000000000000246 R12: fffffffffffffde0
[ 750.463640] [ T9870] R13: 0000000000000020 R14: 0000000000000002 R15: 00007ffc072d2230
[ 750.463965] [ T9870] </TASK>
[ 750.464285] [ T9870] Modules linked in: siw ib_uverbs ccm cmac nls_utf8 cifs cifs_arc4 nls_ucs2_utils rdma_cm iw_cm ib_cm ib_core cifs_md4 netfs softdog vboxsf vboxguest cpuid intel_rapl_msr intel_rapl_common intel_uncore_frequency_common intel_pmc_core pmt_telemetry pmt_class intel_pmc_ssram_telemetry intel_vsec polyval_clmulni ghash_clmulni_intel sha1_ssse3 aesni_intel rapl i2c_piix4 i2c_smbus joydev input_leds mac_hid sunrpc binfmt_misc kvm_intel kvm irqbypass sch_fq_codel efi_pstore nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vsock vmw_vmci dmi_sysfs ip_tables x_tables autofs4 hid_generic vboxvideo usbhid drm_vram_helper psmouse vga16fb vgastate drm_ttm_helper serio_raw hid ahci libahci ttm pata_acpi video wmi [last unloaded: vboxguest]
[ 750.467127] [ T9870] CR2: ffff8880110a2000
cc: Tom Talpey <tom@talpey.com>
cc: linux-cifs@vger.kernel.org
Reviewed-by: David Howells <dhowells@redhat.com>
Reviewed-by: Tom Talpey <tom@talpey.com>
Fixes: c45ebd636c32 ("cifs: Provide the capability to extract from ITER_FOLIOQ to RDMA SGEs")
Signed-off-by: Stefan Metzmacher <metze@samba.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
after fabc4ed200f9, server_unresponsive add a condition to check whether client
need to reconnect depending on server->lstrp. When client failed to reconnect
for some time and abort connection, server->lstrp is updated for the last time.
In the following scene, server->lstrp is too old. This cause next command
failure in re-negotiation rather than waiting for re-negotiation done.
1. mount -t cifs -o username=Everyone,echo_internal=10 //$server_ip/export /mnt
2. ssh $server_ip "echo b > /proc/sysrq-trigger &"
3. ls /mnt
4. sleep 21s
5. ssh $server_ip "service firewalld stop"
6. ls # return EHOSTDOWN
If the interval between 5 and 6 is too small, 6 may trigger sending negotiation
request. Before backgrounding cifsd thread try to receive negotiation response
from server in cifs_readv_from_socket, server_unresponsive may trigger
cifs_reconnect which cause 6 to be failed:
ls thread
----------------
smb2_negotiate
server->tcpStatus = CifsInNegotiate
compound_send_recv
wait_for_compound_request
cifsd thread
----------------
cifs_readv_from_socket
server_unresponsive
server->tcpStatus == CifsInNegotiate && jiffies > server->lstrp + 20s
cifs_reconnect
cifs_abort_connection: mid_state = MID_RETRY_NEEDED
ls thread
----------------
cifs_sync_mid_result return EAGAIN
smb2_negotiate return EHOSTDOWN
Though server->lstrp means last server response time, it is updated in
cifs_abort_connection and cifs_get_tcp_session. We can also update server->lstrp
before switching into CifsInNegotiate state to avoid failure in 6.
Fixes: 7ccc1465465d ("smb: client: fix hang in wait_for_response() for negproto")
Acked-by: Paulo Alcantara (Red Hat) <pc@manguebit.org>
Acked-by: Meetakshi Setiya <msetiya@microsoft.com>
Signed-off-by: zhangjian <zhangjian496@huawei.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
|
|
ath79_misc_irq_init() was defined but unused since commit 51fa4f8912c0
("MIPS: ath79: drop legacy IRQ code"), so it's time to drop it.
The build also warns about a missing prototype of get_c0_perfcount_int().
Remove the stale leftover function and add the missing include.
Signed-off-by: Shiji Yang <yangshiji66@outlook.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/all/OSBPR01MB167032D2017645200787AAEBBC72A@OSBPR01MB1670.jpnprd01.prod.outlook.com
|
|
Currently the call_rcu() API does not check whether a callback
pointer is NULL. If NULL is passed, rcu_core() will try to invoke
it, resulting in NULL pointer dereference and a kernel crash.
To prevent this and improve debuggability, this patch adds a check
for NULL and emits a kernel stack trace to help identify a faulty
caller.
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com>
|
|
Exit to userspace for TDG.VP.VMCALL<GetTdVmCallInfo> via KVM_EXIT_TDX,
to allow userspace to provide information about the support of
TDVMCALLs when r12 is 1 for the TDVMCALLs beyond the GHCI base API.
GHCI spec defines the GHCI base TDVMCALLs: <GetTdVmCallInfo>, <MapGPA>,
<ReportFatalError>, <Instruction.CPUID>, <#VE.RequestMMIO>,
<Instruction.HLT>, <Instruction.IO>, <Instruction.RDMSR> and
<Instruction.WRMSR>. They must be supported by VMM to support TDX guests.
For GetTdVmCallInfo
- When leaf (r12) to enumerate TDVMCALL functionality is set to 0,
successful execution indicates all GHCI base TDVMCALLs listed above are
supported.
Update the KVM TDX document with the set of the GHCI base APIs.
- When leaf (r12) to enumerate TDVMCALL functionality is set to 1, it
indicates the TDX guest is querying the supported TDVMCALLs beyond
the GHCI base TDVMCALLs.
Exit to userspace to let userspace set the TDVMCALL sub-function bit(s)
accordingly to the leaf outputs. KVM could set the TDVMCALL bit(s)
supported by itself when the TDVMCALLs don't need support from userspace
after returning from userspace and before entering guest. Currently, no
such TDVMCALLs implemented, KVM just sets the values returned from
userspace.
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
[Adjust userspace API. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Handle TDVMCALL for GetQuote to generate a TD-Quote.
GetQuote is a doorbell-like interface used by TDX guests to request VMM
to generate a TD-Quote signed by a service hosting TD-Quoting Enclave
operating on the host. A TDX guest passes a TD Report (TDREPORT_STRUCT) in
a shared-memory area as parameter. Host VMM can access it and queue the
operation for a service hosting TD-Quoting enclave. When completed, the
Quote is returned via the same shared-memory area.
KVM only checks the GPA from the TDX guest has the shared-bit set and drops
the shared-bit before exiting to userspace to avoid bleeding the shared-bit
into KVM's exit ABI. KVM forwards the request to userspace VMM (e.g. QEMU)
and userspace VMM queues the operation asynchronously. KVM sets the return
code according to the 'ret' field set by userspace to notify the TDX guest
whether the request has been queued successfully or not. When the request
has been queued successfully, the TDX guest can poll the status field in
the shared-memory area to check whether the Quote generation is completed
or not. When completed, the generated Quote is returned via the same
buffer.
Add KVM_EXIT_TDX as a new exit reason to userspace. Userspace is
required to handle the KVM exit reason as the initial support for TDX,
by reentering KVM to ensure that the TDVMCALL is complete. While at it,
add a note that KVM_EXIT_HYPERCALL also requires reentry with KVM_RUN.
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
Tested-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Acked-by: Kai Huang <kai.huang@intel.com>
[Adjust userspace API. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Add the new TDVMCALL status code TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED and
return it for unimplemented TDVMCALL subfunctions.
Returning TDVMCALL_STATUS_INVALID_OPERAND when a subfunction is not
implemented is vague because TDX guests can't tell the error is due to
the subfunction is not supported or an invalid input of the subfunction.
New GHCI spec adds TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED to avoid the
ambiguity. Use it instead of TDVMCALL_STATUS_INVALID_OPERAND.
Before the change, for common guest implementations, when a TDX guest
receives TDVMCALL_STATUS_INVALID_OPERAND, it has two cases:
1. Some operand is invalid. It could change the operand to another value
retry.
2. The subfunction is not supported.
For case 1, an invalid operand usually means the guest implementation bug.
Since the TDX guest can't tell which case is, the best practice for
handling TDVMCALL_STATUS_INVALID_OPERAND is stopping calling such leaf,
treating the failure as fatal if the TDVMCALL is essential or ignoring
it if the TDVMCALL is optional.
With this change, TDVMCALL_STATUS_SUBFUNC_UNSUPPORTED could be sent to
old TDX guest that do not know about it, but it is expected that the
guest will make the same action as TDVMCALL_STATUS_INVALID_OPERAND.
Currently, no known TDX guest checks TDVMCALL_STATUS_INVALID_OPERAND
specifically; for example Linux just checks for success.
Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com>
[Return it for untrapped KVM_HC_MAP_GPA_RANGE. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
It is possible when an inode is split into segments for multi-threaded
compression, and the tail extent of a segment could also be small.
Fixes: 1d191b4ca51d ("erofs: implement encoded extent metadata")
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20250620153108.1368029-1-hsiangkao@linux.alibaba.com
|
|
A previous fix corrected the retry condition for when to continue a
current bundle, but it missed that the current (not the total) transfer
count also applies to the buffer put. If not, then for incrementally
consumed buffer rings repeated completions on the same request may end
up over consuming.
Reported-by: Roy Tang (ErgoniaTrading) <royonia@ergonia.io>
Cc: stable@vger.kernel.org
Fixes: 3a08988123c8 ("io_uring/net: only retry recv bundle for a full transfer")
Link: https://github.com/axboe/liburing/issues/1423
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Positivo P15X is equipped with ALC269VC, and needs a fix to make
the headset mic to work.
Also must to limits the internal microphone boost.
Signed-off-by: Edson Juliano Drosdeck <edson.drosdeck@gmail.com>
Link: https://patch.msgid.link/20250619191215.17203-1-edson.drosdeck@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Memory allocated for the ECC engine conf is not released during spinand
cleanup. Below kmemleak trace is seen for this memory leak:
unreferenced object 0xffffff80064f00e0 (size 8):
comm "swapper/0", pid 1, jiffies 4294937458
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00 ........
backtrace (crc 0):
kmemleak_alloc+0x30/0x40
__kmalloc_cache_noprof+0x208/0x3c0
spinand_ondie_ecc_init_ctx+0x114/0x200
nand_ecc_init_ctx+0x70/0xa8
nanddev_ecc_engine_init+0xec/0x27c
spinand_probe+0xa2c/0x1620
spi_mem_probe+0x130/0x21c
spi_probe+0xf0/0x170
really_probe+0x17c/0x6e8
__driver_probe_device+0x17c/0x21c
driver_probe_device+0x58/0x180
__device_attach_driver+0x15c/0x1f8
bus_for_each_drv+0xec/0x150
__device_attach+0x188/0x24c
device_initial_probe+0x10/0x20
bus_probe_device+0x11c/0x160
Fix the leak by calling nanddev_ecc_engine_cleanup() inside
spinand_cleanup().
Signed-off-by: Pablo Martin-Gomez <pmartin-gomez@freebox.fr>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
|
|
EN7581 SoC allows configuring the size and the number of buffers in
hwfd payload queue for both QDMA0 and QDMA1.
In order to reduce the required DRAM used for hwfd buffers queues and
decrease the memory footprint, differentiate hwfd buffer size for QDMA0
and QDMA1 and reduce hwfd buffer size to 1KB for QDMA1 (WAN) while
maintaining 2KB for QDMA0 (LAN).
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250619-airoha-hw-num-desc-v4-2-49600a9b319a@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
In order to not exceed the reserved memory size for hwfd buffers,
compute the number of hwfd buffers/descriptors according to the
reserved memory size and the size of each hwfd buffer (2KB).
Fixes: 3a1ce9e3d01b ("net: airoha: Add the capability to allocate hwfd buffers via reserved-memory")
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250619-airoha-hw-num-desc-v4-1-49600a9b319a@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The multi message support loosened the connection between the request
and response handling, as we can now submit multiple requests before
we start processing responses. Passing the attr set to NlMsgs decoding
no longer makes sense (if it ever did), attr set may differ message
by messsage. Isolate the part of decoding responsible for attr-set
specific interpretation and call it once we identified the correct op.
Without this fix performing SET operation on an ethtool socket, while
being subscribed to notifications causes:
# File "tools/net/ynl/pyynl/lib/ynl.py", line 1096, in _op
# Exception| return self._ops(ops)[0]
# Exception| ~~~~~~~~~^^^^^
# File "tools/net/ynl/pyynl/lib/ynl.py", line 1040, in _ops
# Exception| nms = NlMsgs(reply, attr_space=op.attr_set)
# Exception| ^^^^^^^^^^^
The value of op we use on line 1040 is stale, it comes form the previous
loop. If a notification comes before a response we will update op to None
and the next iteration thru the loop will break with the trace above.
Fixes: 6fda63c45fe8 ("tools/net/ynl: fix cli.py --subscribe feature")
Fixes: ba8be00f68f5 ("tools/net/ynl: Add multi message support to ynl")
Reviewed-by: Donald Hunter <donald.hunter@gmail.com>
Link: https://patch.msgid.link/20250618171746.1201403-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
/proc/net/atm/lec must ensure safety against dev_lec[] changes.
It appears it had dev_put() calls without prior dev_hold(),
leading to imbalance and UAF.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com> # Minor atm contributor
Link: https://patch.msgid.link/20250618140844.1686882-3-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
syzbot found its way in net/atm/lec.c, and found an error path
in lecd_attach() could leave a dangling pointer in dev_lec[].
Add a mutex to protect dev_lecp[] uses from lecd_attach(),
lec_vcc_attach() and lec_mcast_attach().
Following patch will use this mutex for /proc/net/atm/lec.
BUG: KASAN: slab-use-after-free in lecd_attach net/atm/lec.c:751 [inline]
BUG: KASAN: slab-use-after-free in lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008
Read of size 8 at addr ffff88807c7b8e68 by task syz.1.17/6142
CPU: 1 UID: 0 PID: 6142 Comm: syz.1.17 Not tainted 6.16.0-rc1-syzkaller-00239-g08215f5486ec #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xcd/0x680 mm/kasan/report.c:521
kasan_report+0xe0/0x110 mm/kasan/report.c:634
lecd_attach net/atm/lec.c:751 [inline]
lane_ioctl+0x2224/0x23e0 net/atm/lec.c:1008
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x118/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
Allocated by task 6132:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
__kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
kasan_kmalloc include/linux/kasan.h:260 [inline]
__do_kmalloc_node mm/slub.c:4328 [inline]
__kvmalloc_node_noprof+0x27b/0x620 mm/slub.c:5015
alloc_netdev_mqs+0xd2/0x1570 net/core/dev.c:11711
lecd_attach net/atm/lec.c:737 [inline]
lane_ioctl+0x17db/0x23e0 net/atm/lec.c:1008
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x118/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 6132:
kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:576
poison_slab_object mm/kasan/common.c:247 [inline]
__kasan_slab_free+0x51/0x70 mm/kasan/common.c:264
kasan_slab_free include/linux/kasan.h:233 [inline]
slab_free_hook mm/slub.c:2381 [inline]
slab_free mm/slub.c:4643 [inline]
kfree+0x2b4/0x4d0 mm/slub.c:4842
free_netdev+0x6c5/0x910 net/core/dev.c:11892
lecd_attach net/atm/lec.c:744 [inline]
lane_ioctl+0x1ce8/0x23e0 net/atm/lec.c:1008
do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159
sock_do_ioctl+0x118/0x280 net/socket.c:1190
sock_ioctl+0x227/0x6b0 net/socket.c:1311
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:907 [inline]
__se_sys_ioctl fs/ioctl.c:893 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:893
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+8b64dec3affaed7b3af5@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6852c6f6.050a0220.216029.0018.GAE@google.com/T/#u
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20250618140844.1686882-2-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The message "Error getting PHY irq. Use polling instead"
is emitted when the mlxbf_gige driver is loaded by the
kernel before the associated gpio-mlxbf driver, and thus
the call to get the PHY IRQ fails since it is not yet
available. The driver probe() must return -EPROBE_DEFER
if acpi_dev_gpio_irq_get_by() returns the same.
Fixes: 6c2a6ddca763 ("net: mellanox: mlxbf_gige: Replace non-standard interrupt handling")
Signed-off-by: David Thompson <davthompson@nvidia.com>
Reviewed-by: Asmaa Mnebhi <asmaa@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250618135902.346-1-davthompson@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
airoha_ppe_foe_get_entry routine can return NULL, so check the returned
pointer is not NULL in airoha_ppe_foe_flow_l2_entry_update()
Fixes: b81e0f2b58be3 ("net: airoha: Add FLOW_CLS_STATS callback support")
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Link: https://patch.msgid.link/20250618-check-ret-from-airoha_ppe_foe_get_entry-v2-1-068dcea3cc66@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Setting tty->disc_data before opening the NCI device means we need to
clean it up on error paths. This also opens some short window if device
starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded
(broken hardware?). Close the window by exposing tty->disc_data only on
the success path, when opening of the NCI device and try_module_get()
succeeds.
The code differs in error path in one aspect: tty->disc_data won't be
ever assigned thus NULL-ified. This however should not be relevant
difference, because of "tty->disc_data=NULL" in nci_uart_tty_open().
Cc: Linus Torvalds <torvalds@linuxfoundation.org>
Fixes: 9961127d4bce ("NFC: nci: add generic uart support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/20250618073649.25049-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
syzkaller reported a null-ptr-deref in sock_omalloc() while allocating
a CALIPSO option. [0]
The NULL is of struct sock, which was fetched by sk_to_full_sk() in
calipso_req_setattr().
Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"),
reqsk->rsk_listener could be NULL when SYN Cookie is returned to its
client, as hinted by the leading SYN Cookie log.
Here are 3 options to fix the bug:
1) Return 0 in calipso_req_setattr()
2) Return an error in calipso_req_setattr()
3) Alaways set rsk_listener
1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie
for CALIPSO. 3) is also no go as there have been many efforts to reduce
atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35
("tcp/dccp: do not touch listener sk_refcnt under synflood").
As of the blamed commit, SYN Cookie already did not need refcounting,
and no one has stumbled on the bug for 9 years, so no CALIPSO user will
care about SYN Cookie.
Let's return an error in calipso_req_setattr() and calipso_req_delattr()
in the SYN Cookie case.
This can be reproduced by [1] on Fedora and now connect() of nc times out.
[0]:
TCP: request_sock_TCPv6: Possible SYN flooding on port [::]:20002. Sending cookies.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
RIP: 0010:read_pnet include/net/net_namespace.h:406 [inline]
RIP: 0010:sock_net include/net/sock.h:655 [inline]
RIP: 0010:sock_kmalloc+0x35/0x170 net/core/sock.c:2806
Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b
RSP: 0018:ffff88811af89038 EFLAGS: 00010216
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400
RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030
RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e
R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000
R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050
FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0
PKRU: 80000000
Call Trace:
<IRQ>
ipv6_renew_options+0x279/0x950 net/ipv6/exthdrs.c:1288
calipso_req_setattr+0x181/0x340 net/ipv6/calipso.c:1204
calipso_req_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:597
netlbl_req_setattr+0x18a/0x440 net/netlabel/netlabel_kapi.c:1249
selinux_netlbl_inet_conn_request+0x1fb/0x320 security/selinux/netlabel.c:342
selinux_inet_conn_request+0x1eb/0x2c0 security/selinux/hooks.c:5551
security_inet_conn_request+0x50/0xa0 security/security.c:4945
tcp_v6_route_req+0x22c/0x550 net/ipv6/tcp_ipv6.c:825
tcp_conn_request+0xec8/0x2b70 net/ipv4/tcp_input.c:7275
tcp_v6_conn_request+0x1e3/0x440 net/ipv6/tcp_ipv6.c:1328
tcp_rcv_state_process+0xafa/0x52b0 net/ipv4/tcp_input.c:6781
tcp_v6_do_rcv+0x8a6/0x1a40 net/ipv6/tcp_ipv6.c:1667
tcp_v6_rcv+0x505e/0x5b50 net/ipv6/tcp_ipv6.c:1904
ip6_protocol_deliver_rcu+0x17c/0x1da0 net/ipv6/ip6_input.c:436
ip6_input_finish+0x103/0x180 net/ipv6/ip6_input.c:480
NF_HOOK include/linux/netfilter.h:314 [inline]
NF_HOOK include/linux/netfilter.h:308 [inline]
ip6_input+0x13c/0x6b0 net/ipv6/ip6_input.c:491
dst_input include/net/dst.h:469 [inline]
ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline]
ip6_rcv_finish+0xb6/0x490 net/ipv6/ip6_input.c:69
NF_HOOK include/linux/netfilter.h:314 [inline]
NF_HOOK include/linux/netfilter.h:308 [inline]
ipv6_rcv+0xf9/0x490 net/ipv6/ip6_input.c:309
__netif_receive_skb_one_core+0x12e/0x1f0 net/core/dev.c:5896
__netif_receive_skb+0x1d/0x170 net/core/dev.c:6009
process_backlog+0x41e/0x13b0 net/core/dev.c:6357
__napi_poll+0xbd/0x710 net/core/dev.c:7191
napi_poll net/core/dev.c:7260 [inline]
net_rx_action+0x9de/0xde0 net/core/dev.c:7382
handle_softirqs+0x19a/0x770 kernel/softirq.c:561
do_softirq.part.0+0x36/0x70 kernel/softirq.c:462
</IRQ>
<TASK>
do_softirq arch/x86/include/asm/preempt.h:26 [inline]
__local_bh_enable_ip+0xf1/0x110 kernel/softirq.c:389
local_bh_enable include/linux/bottom_half.h:33 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]
__dev_queue_xmit+0xc2a/0x3c40 net/core/dev.c:4679
dev_queue_xmit include/linux/netdevice.h:3313 [inline]
neigh_hh_output include/net/neighbour.h:523 [inline]
neigh_output include/net/neighbour.h:537 [inline]
ip6_finish_output2+0xd69/0x1f80 net/ipv6/ip6_output.c:141
__ip6_finish_output net/ipv6/ip6_output.c:215 [inline]
ip6_finish_output+0x5dc/0xd60 net/ipv6/ip6_output.c:226
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x24b/0x8d0 net/ipv6/ip6_output.c:247
dst_output include/net/dst.h:459 [inline]
NF_HOOK include/linux/netfilter.h:314 [inline]
NF_HOOK include/linux/netfilter.h:308 [inline]
ip6_xmit+0xbbc/0x20d0 net/ipv6/ip6_output.c:366
inet6_csk_xmit+0x39a/0x720 net/ipv6/inet6_connection_sock.c:135
__tcp_transmit_skb+0x1a7b/0x3b40 net/ipv4/tcp_output.c:1471
tcp_transmit_skb net/ipv4/tcp_output.c:1489 [inline]
tcp_send_syn_data net/ipv4/tcp_output.c:4059 [inline]
tcp_connect+0x1c0c/0x4510 net/ipv4/tcp_output.c:4148
tcp_v6_connect+0x156c/0x2080 net/ipv6/tcp_ipv6.c:333
__inet_stream_connect+0x3a7/0xed0 net/ipv4/af_inet.c:677
tcp_sendmsg_fastopen+0x3e2/0x710 net/ipv4/tcp.c:1039
tcp_sendmsg_locked+0x1e82/0x3570 net/ipv4/tcp.c:1091
tcp_sendmsg+0x2f/0x50 net/ipv4/tcp.c:1358
inet6_sendmsg+0xb9/0x150 net/ipv6/af_inet6.c:659
sock_sendmsg_nosec net/socket.c:718 [inline]
__sock_sendmsg+0xf4/0x2a0 net/socket.c:733
__sys_sendto+0x29a/0x390 net/socket.c:2187
__do_sys_sendto net/socket.c:2194 [inline]
__se_sys_sendto net/socket.c:2190 [inline]
__x64_sys_sendto+0xe1/0x1c0 net/socket.c:2190
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xc3/0x1d0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f06553c47ed
Code: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f0653a06fc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f0655605fa0 RCX: 00007f06553c47ed
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000000000b
RBP: 00007f065545db38 R08: 0000200000000140 R09: 000000000000001c
R10: f7384d4ea84b01bd R11: 0000000000000246 R12: 0000000000000000
R13: 00007f0655605fac R14: 00007f0655606038 R15: 00007f06539e7000
</TASK>
Modules linked in:
[1]:
dnf install -y selinux-policy-targeted policycoreutils netlabel_tools procps-ng nmap-ncat
mount -t selinuxfs none /sys/fs/selinux
load_policy
netlabelctl calipso add pass doi:1
netlabelctl map del default
netlabelctl map add default address:::1 protocol:calipso,1
sysctl net.ipv4.tcp_syncookies=2
nc -l ::1 80 &
nc ::1 80
Fixes: e1adea927080 ("calipso: Allow request sockets to be relabelled by the lsm.")
Reported-by: syzkaller <syzkaller@googlegroups.com>
Reported-by: John Cheung <john.cs.hey@gmail.com>
Closes: https://lore.kernel.org/netdev/CAP=Rh=MvfhrGADy+-WJiftV2_WzMH4VEhEFmeT28qY+4yxNu4w@mail.gmail.com/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Acked-by: Paul Moore <paul@paul-moore.com>
Link: https://patch.msgid.link/20250617224125.17299-1-kuni1840@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
Philip Yang
Kent Russell
David Yat Sin
Alex Deucher
Michal Wajdeczko
Matthew Auld
Maarten Lankhorst
Jayesh Choudhary
Arnd Bergmann
Karthik Poosa
Haoxiang Li
Takashi Iwai
Mario Limonciello
Srinivasan Shanmugam
Chaoyi Chen
Imre Deak
Ankit Nautiyal
Louis Chauvet
Linus Torvalds
Alex Elder
Bharath SM
Paul Aurich
David Howells
Stefan Metzmacher
zhangjian
Shiji Yang
Uladzislau Rezki (Sony)
Binbin Wu
Gao Xiang
Jens Axboe
Edson Juliano Drosdeck
Pablo Martin-Gomez
Lorenzo Bianconi
Jakub Kicinski
Eric Dumazet
David Thompson
Krzysztof Kozlowski
Kuniyuki Iwashima