build(deps): bump urllib3 from 2.0.7 to 2.2.2 in /drivers/gpu/drm/ci/xfails#3
Open
dependabot[bot] wants to merge 10 commits intolinux-nextfrom
Open
Conversation
* thermal-core: thermal: gov_power_allocator: Avoid overwriting PID coefficients from setup time thermal: sysfs: Fix up white space in trip_point_temp_store() iwlwifi: mvm: Use for_each_thermal_trip() for walking trip points iwlwifi: mvm: Populate trip table before registering thermal zone iwlwifi: mvm: Drop unused fw_trips_index[] from iwl_mvm_thermal_device thermal: core: Change governor name to const char pointer thermal: gov_bang_bang: Fix possible cooling device state ping-pong thermal: gov_fair_share: Fix dependency on trip points ordering * thermal-intel: thermal/intel: Fix intel_tcc_get_temp() to support negative CPU temperature
… into linux-next * acpi-pm: ACPI: PM: s2idle: Enable Low-Power S0 Idle MSFT UUID for non-AMD systems * acpi-resource: ACPI: resource: Do IRQ override on Lunnen Ground laptops ACPI: resource: Add IRQ override quirk for ASUS ExpertBook B2502FBA ACPI: resource: Skip IRQ override on ASUS ExpertBook B1502CVA * acpi-bus: ACPI: bus: make acpi_bus_type const * acpi-scan: ACPI: scan: Defer enumeration of devices with a _DEP pointing to IVSC device
…-processor' into linux-next * acpi-tables: ACPI: NFIT: Switch to use acpi_evaluate_dsm_typed() * acpi-video: ACPI: video: Handle fetching EDID that is longer than 256 bytes * acpi-property: ACPI: property: Ignore bad graph port nodes on Dell XPS 9315 ACPI: utils: Make acpi_handle_path() not static * acpi-processor: ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
* pm-sleep: Documentation: PM: Fix PCI hibernation support description PM: hibernate: Add support for LZ4 compression for hibernation PM: hibernate: Move to crypto APIs for LZO compression PM: hibernate: Rename lzo* to make it generic PM: sleep: Call dpm_async_fn() directly in each suspend phase PM: sleep: Move devices to new lists earlier in each suspend phase PM: sleep: Move some assignments from under a lock PM: sleep: stats: Log errors right after running suspend callbacks PM: sleep: stats: Use locking in dpm_save_failed_dev() PM: sleep: stats: Call dpm_save_failed_step() at most once per phase PM: sleep: stats: Define suspend_stats next to the code using it PM: sleep: stats: Use unsigned int for success and failure counters PM: sleep: stats: Use an array of step failure counters PM: sleep: stats: Use array of suspend step names PM: sleep: Relocate two device PM core functions PM: sleep: Simplify dpm_suspended_list walk in dpm_resume() PM: sleep: Use bool for all 1-bit fields in struct dev_pm_info
* pm-cpufreq: cpufreq: intel_pstate: remove cpudata::prev_cummulative_iowait cpufreq: Change default transition delay to 2ms cpufreq: amd-pstate: Fix min_perf assignment in amd_pstate_adjust_perf() Documentation: PM: amd-pstate: Fix section title underline Documentation: introduce amd-pstate preferrd core mode kernel command line options Documentation: amd-pstate: introduce amd-pstate preferred core cpufreq: amd-pstate: Update amd-pstate preferred core ranking dynamically ACPI: cpufreq: Add highest perf change notification cpufreq: amd-pstate: Enable amd-pstate preferred core support ACPI: CPPC: Add helper to get the highest performance value x86: Drop CPU_SUP_INTEL from SCHED_MC_PRIO for the expansion * pm-cpuidle: cpuidle: Avoid potential overflow in integer multiplication cpuidle: haltpoll: do not shrink guest poll_limit_ns below grow_start
* pm-powercap: powercap: dtpm_cpu: Fix error check against freq_qos_add_request() powercap: intel_rapl: Add support for Arrow Lake powercap: intel_rapl: Add support for Lunar Lake-M paltform powercap: intel_rapl_tpmi: Fix System Domain probing powercap: intel_rapl_tpmi: Fix a register bug powercap: intel_rapl: Fix locking in TPMI RAPL powercap: intel_rapl: Fix a NULL pointer dereference
* pm-em: (23 commits) Documentation: EM: Update with runtime modification design PM: EM: Add em_dev_compute_costs() PM: EM: Remove old table PM: EM: Change debugfs configuration to use runtime EM table data drivers/thermal/devfreq_cooling: Use new Energy Model interface drivers/thermal/cpufreq_cooling: Use new Energy Model interface powercap/dtpm_devfreq: Use new Energy Model interface to get table powercap/dtpm_cpu: Use new Energy Model interface to get table PM: EM: Optimize em_cpu_energy() and remove division PM: EM: Support late CPUs booting and capacity adjustment PM: EM: Add performance field to struct em_perf_state and optimize PM: EM: Add em_perf_state_from_pd() to get performance states table PM: EM: Introduce em_dev_update_perf_domain() for EM updates PM: EM: Add functions for memory allocations for new EM tables PM: EM: Use runtime modified EM for CPUs energy estimation in EAS PM: EM: Introduce runtime modifiable table PM: EM: Split the allocation and initialization of the EM table PM: EM: Check if the get_cost() callback is present in em_compute_costs() PM: EM: Introduce em_compute_costs() PM: EM: Refactor em_pd_get_efficient_state() to be more flexible ...
* pm-runtime: PM: runtime: Add pm_runtime_put_autosuspend() replacement PM: runtime: Simplify pm_runtime_get_if_active() usage
* acpi-misc: ACPI: use %pe for better readability of errors while printing
Bumps [urllib3](https://github.com/urllib3/urllib3) from 2.0.7 to 2.2.2. - [Release notes](https://github.com/urllib3/urllib3/releases) - [Changelog](https://github.com/urllib3/urllib3/blob/main/CHANGES.rst) - [Commits](urllib3/urllib3@2.0.7...2.2.2) --- updated-dependencies: - dependency-name: urllib3 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
the
dependencies
rafaeljw
pushed a commit
that referenced
this pull request
Feb 26, 2026
firmware populates MAC address, link modes (supported, advertised) and EEPROM data in shared firmware structure which kernel access via MAC block(CGX/RPM). Accessing fwdata, on boards booted with out MAC block leading to kernel panics. Internal error: Oops: 0000000096000005 [#1] SMP [ 10.460721] Modules linked in: [ 10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT [ 10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT) [ 10.479793] Workqueue: events work_for_cpu_fn [ 10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 10.491124] pc : rvu_sdp_init+0x18/0x114 [ 10.495051] lr : rvu_probe+0xe58/0x1d18 Fixes: 9978144 ("Octeontx2-af: Fetch MAC channel info from firmware") Fixes: 5f21226 ("Octeontx2-pf: ethtool: support multi advertise mode") Signed-off-by: Hariprasad Kelam <hkelam@marvell.com> Link: https://patch.msgid.link/20260121094819.2566786-1-hkelam@marvell.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rafaeljw
pushed a commit
that referenced
this pull request
Feb 27, 2026
…ming
KASAN reports a NULL instruction fetch (RIP=0x0) from
dc_stream_program_cursor_position():
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:0x0
Call Trace:
dc_stream_program_cursor_position+0x344/0x920 [amdgpu]
amdgpu_dm_atomic_commit_tail+...
[ +1.041013] BUG: kernel NULL pointer dereference, address: 0000000000000000
[ +0.000027] #PF: supervisor instruction fetch in kernel mode
[ +0.000013] #PF: error_code(0x0010) - not-present page
[ +0.000012] PGD 0 P4D 0
[ +0.000017] Oops: Oops: 0010 [#1] SMP KASAN NOPTI
[ +0.000017] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Tainted: G E 6.18.0+ #3 PREEMPT(voluntary)
[ +0.000023] Tainted: [E]=UNSIGNED_MODULE
[ +0.000010] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[ +0.000016] Workqueue: events drm_mode_rmfb_work_fn
[ +0.000022] RIP: 0010:0x0
[ +0.000017] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[ +0.000015] RSP: 0018:ffffc9000017f4c8 EFLAGS: 00010246
[ +0.000016] RAX: 0000000000000000 RBX: ffff88810afdda80 RCX: 1ffff110457000d1
[ +0.000014] RDX: 1ffffffff87b75bd RSI: 0000000000000000 RDI: ffff88810afdda80
[ +0.000014] RBP: ffffc9000017f538 R08: 0000000000000000 R09: ffff88822b800690
[ +0.000013] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffc3dbac20
[ +0.000014] R13: 0000000000000000 R14: ffff88811ab80000 R15: dffffc0000000000
[ +0.000014] FS: 0000000000000000(0000) GS:ffff888434599000(0000) knlGS:0000000000000000
[ +0.000015] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ +0.000013] CR2: ffffffffffffffd6 CR3: 000000010ee88000 CR4: 0000000000350ef0
[ +0.000014] Call Trace:
[ +0.000010] <TASK>
[ +0.000010] dc_stream_program_cursor_position+0x344/0x920 [amdgpu]
[ +0.001086] ? __pfx_mutex_lock+0x10/0x10
[ +0.000015] ? unwind_next_frame+0x18b/0xa70
[ +0.000019] amdgpu_dm_atomic_commit_tail+0x1124/0xfa20 [amdgpu]
[ +0.001040] ? ret_from_fork_asm+0x1a/0x30
[ +0.000018] ? filter_irq_stacks+0x90/0xa0
[ +0.000022] ? __pfx_amdgpu_dm_atomic_commit_tail+0x10/0x10 [amdgpu]
[ +0.001058] ? kasan_save_track+0x18/0x70
[ +0.000015] ? kasan_save_alloc_info+0x37/0x60
[ +0.000015] ? __kasan_kmalloc+0xc3/0xd0
[ +0.000013] ? __kmalloc_cache_noprof+0x1aa/0x600
[ +0.000016] ? drm_atomic_helper_setup_commit+0x788/0x1450
[ +0.000017] ? drm_atomic_helper_commit+0x7e/0x290
[ +0.000014] ? drm_atomic_commit+0x205/0x2e0
[ +0.000015] ? process_one_work+0x629/0xf80
[ +0.000016] ? worker_thread+0x87f/0x1570
[ +0.000020] ? srso_return_thunk+0x5/0x5f
[ +0.000014] ? __kasan_check_write+0x14/0x30
[ +0.000014] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? _raw_spin_lock_irq+0x8a/0xf0
[ +0.000015] ? __pfx__raw_spin_lock_irq+0x10/0x10
[ +0.000016] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_write+0x14/0x30
[ +0.000014] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __wait_for_common+0x204/0x460
[ +0.000015] ? sched_clock_noinstr+0x9/0x10
[ +0.000014] ? __pfx_schedule_timeout+0x10/0x10
[ +0.000014] ? local_clock_noinstr+0xe/0xd0
[ +0.000015] ? __pfx___wait_for_common+0x10/0x10
[ +0.000014] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __wait_for_common+0x204/0x460
[ +0.000014] ? __pfx_schedule_timeout+0x10/0x10
[ +0.000015] ? __kasan_kmalloc+0xc3/0xd0
[ +0.000015] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? wait_for_completion_timeout+0x1d/0x30
[ +0.000015] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? drm_crtc_commit_wait+0x32/0x180
[ +0.000015] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? drm_atomic_helper_wait_for_dependencies+0x46a/0x800
[ +0.000019] commit_tail+0x231/0x510
[ +0.000017] drm_atomic_helper_commit+0x219/0x290
[ +0.000015] ? __pfx_drm_atomic_helper_commit+0x10/0x10
[ +0.000016] drm_atomic_commit+0x205/0x2e0
[ +0.000014] ? __pfx_drm_atomic_commit+0x10/0x10
[ +0.000013] ? __pfx_drm_connector_free+0x10/0x10
[ +0.000014] ? __pfx___drm_printfn_info+0x10/0x10
[ +0.000017] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? drm_atomic_set_crtc_for_connector+0x49e/0x660
[ +0.000015] ? drm_atomic_set_fb_for_plane+0x155/0x290
[ +0.000015] drm_framebuffer_remove+0xa9b/0x1240
[ +0.000014] ? finish_task_switch.isra.0+0x15a/0x840
[ +0.000015] ? __switch_to+0x385/0xda0
[ +0.000015] ? srso_safe_ret+0x1/0x20
[ +0.000013] ? __pfx_drm_framebuffer_remove+0x10/0x10
[ +0.000016] ? kasan_print_address_stack_frame+0x221/0x280
[ +0.000015] drm_mode_rmfb_work_fn+0x14b/0x240
[ +0.000015] process_one_work+0x629/0xf80
[ +0.000012] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_write+0x14/0x30
[ +0.000019] worker_thread+0x87f/0x1570
[ +0.000013] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ +0.000014] ? __pfx_try_to_wake_up+0x10/0x10
[ +0.000017] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? kasan_print_address_stack_frame+0x227/0x280
[ +0.000017] ? __pfx_worker_thread+0x10/0x10
[ +0.000014] kthread+0x396/0x830
[ +0.000013] ? __pfx__raw_spin_lock_irq+0x10/0x10
[ +0.000015] ? __pfx_kthread+0x10/0x10
[ +0.000012] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __kasan_check_write+0x14/0x30
[ +0.000014] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? recalc_sigpending+0x180/0x210
[ +0.000015] ? srso_return_thunk+0x5/0x5f
[ +0.000013] ? __pfx_kthread+0x10/0x10
[ +0.000014] ret_from_fork+0x31c/0x3e0
[ +0.000014] ? __pfx_kthread+0x10/0x10
[ +0.000013] ret_from_fork_asm+0x1a/0x30
[ +0.000019] </TASK>
[ +0.000010] Modules linked in: rfcomm(E) cmac(E) algif_hash(E) algif_skcipher(E) af_alg(E) snd_seq_dummy(E) snd_hrtimer(E) qrtr(E) xt_MASQUERADE(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) xt_mark(E) xt_tcpudp(E) nft_compat(E) nf_tables(E) x_tables(E) bnep(E) snd_hda_codec_alc882(E) snd_hda_codec_atihdmi(E) snd_hda_codec_realtek_lib(E) snd_hda_codec_hdmi(E) snd_hda_codec_generic(E) iwlmvm(E) snd_hda_intel(E) binfmt_misc(E) snd_hda_codec(E) snd_hda_core(E) mac80211(E) snd_intel_dspcfg(E) snd_intel_sdw_acpi(E) snd_hwdep(E) snd_pcm(E) libarc4(E) snd_seq_midi(E) snd_seq_midi_event(E) snd_rawmidi(E) amd_atl(E) intel_rapl_msr(E) snd_seq(E) intel_rapl_common(E) iwlwifi(E) jc42(E) snd_seq_device(E) btusb(E) snd_timer(E) btmtk(E) btrtl(E) edac_mce_amd(E) eeepc_wmi(E) polyval_clmulni(E) btbcm(E) ghash_clmulni_intel(E) asus_wmi(E) ee1004(E) platform_profile(E) btintel(E) snd(E) nls_iso8859_1(E) aesni_intel(E) soundcore(E) i2c_piix4(E) cfg80211(E) sparse_keymap(E) wmi_bmof(E) bluetooth(E) k10temp(E) rapl(E)
[ +0.000300] i2c_smbus(E) ccp(E) joydev(E) input_leds(E) gpio_amdpt(E) mac_hid(E) sch_fq_codel(E) msr(E) parport_pc(E) ppdev(E) lp(E) parport(E) efi_pstore(E) nfnetlink(E) dmi_sysfs(E) autofs4(E) cdc_ether(E) usbnet(E) amdgpu(E) amdxcp(E) hid_generic(E) i2c_algo_bit(E) drm_ttm_helper(E) ttm(E) drm_exec(E) drm_panel_backlight_quirks(E) gpu_sched(E) drm_suballoc_helper(E) video(E) drm_buddy(E) usbhid(E) drm_display_helper(E) r8152(E) hid(E) mii(E) cec(E) ahci(E) rc_core(E) igc(E) libahci(E) wmi(E)
[ +0.000294] CR2: 0000000000000000
[ +0.000013] ---[ end trace 0000000000000000 ]---
The crash happens when we unconditionally call into the timing generator
manual trigger hook:
pipe_ctx->stream_res.tg->funcs->program_manual_trigger(...)
On some configurations the timing generator (tg), its funcs table, or the
program_manual_trigger callback can be NULL. Guard all of these before
calling the hook. If the first pipe matching the stream cannot trigger,
keep scanning to find another matching pipe with a valid hook.
The issue was originally found on Vg20/DCE 12.1
Mario successfully tested on Polaris 11/DCE 11.2
Cc: Aurabindo Pillai <aurabindo.pillai@amd.com>
Cc: Alexander Deucher <alexander.deucher@amd.com>
Cc: Christian Koenig <christian.koenig@amd.com>
Fixes: ba448f9 ("drm/amd/display: mouse event trigger to boost RR when idle")
Suggested-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
Reviewed-and-tested-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
rafaeljw
pushed a commit
that referenced
this pull request
Feb 27, 2026
With PREEMPT_RT as potential configuration option, spinlock_t is now
considered as a sleeping lock, and thus might cause issues when used in
an atomic context. But even with PREEMPT_RT as potential configuration
option, raw_spinlock_t remains as a true spinning lock/atomic context.
This creates potential issues with the s390 debug/tracing feature. The
functions to trace errors are called in various contexts, including
under lock of raw_spinlock_t, and thus the used spinlock_t in each debug
area is in violation of the locking semantics.
Here are two examples involving failing PCI Read accesses that are
traced while holding `pci_lock` in `drivers/pci/access.c`:
=============================
[ BUG: Invalid wait context ]
6.19.0-devel #18 Not tainted
-----------------------------
bash/3833 is trying to lock:
0000027790baee30 (&rc->lock){-.-.}-{3:3}, at: debug_event_common+0xfc/0x300
other info that might help us debug this:
context-{5:5}
5 locks held by bash/3833:
#0: 0000027efbb29450 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x7c/0xf0
#1: 00000277f0504a90 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x13e/0x260
#2: 00000277beed8c18 (kn->active#339){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x164/0x260
#3: 00000277e9859190 (&dev->mutex){....}-{4:4}, at: pci_dev_lock+0x2e/0x40
#4: 00000383068a7708 (pci_lock){....}-{2:2}, at: pci_bus_read_config_dword+0x4a/0xb0
stack backtrace:
CPU: 6 UID: 0 PID: 3833 Comm: bash Kdump: loaded Not tainted 6.19.0-devel #18 PREEMPTLAZY
Hardware name: IBM 9175 ME1 701 (LPAR)
Call Trace:
[<00000383048afec2>] dump_stack_lvl+0xa2/0xe8
[<00000383049ba166>] __lock_acquire+0x816/0x1660
[<00000383049bb1fa>] lock_acquire+0x24a/0x370
[<00000383059e3860>] _raw_spin_lock_irqsave+0x70/0xc0
[<00000383048bbb6c>] debug_event_common+0xfc/0x300
[<0000038304900b0a>] __zpci_load+0x17a/0x1f0
[<00000383048fad88>] pci_read+0x88/0xd0
[<00000383054cbce0>] pci_bus_read_config_dword+0x70/0xb0
[<00000383054d55e4>] pci_dev_wait+0x174/0x290
[<00000383054d5a3e>] __pci_reset_function_locked+0xfe/0x170
[<00000383054d9b30>] pci_reset_function+0xd0/0x100
[<00000383054ee21a>] reset_store+0x5a/0x80
[<0000038304e98758>] kernfs_fop_write_iter+0x1e8/0x260
[<0000038304d995da>] new_sync_write+0x13a/0x180
[<0000038304d9c5d0>] vfs_write+0x200/0x330
[<0000038304d9c88c>] ksys_write+0x7c/0xf0
[<00000383059cfa80>] __do_syscall+0x210/0x500
[<00000383059e4c06>] system_call+0x6e/0x90
INFO: lockdep is turned off.
=============================
[ BUG: Invalid wait context ]
6.19.0-devel #3 Not tainted
-----------------------------
bash/6861 is trying to lock:
0000009da05c7430 (&rc->lock){-.-.}-{3:3}, at: debug_event_common+0xfc/0x300
other info that might help us debug this:
context-{5:5}
5 locks held by bash/6861:
#0: 000000acff404450 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x7c/0xf0
#1: 000000acff41c490 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x13e/0x260
#2: 0000009da36937d8 (kn->active#75){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x164/0x260
#3: 0000009dd15250d0 (&zdev->state_lock){+.+.}-{4:4}, at: enable_slot+0x2e/0xc0
#4: 000001a19682f708 (pci_lock){....}-{2:2}, at: pci_bus_read_config_byte+0x42/0xa0
stack backtrace:
CPU: 16 UID: 0 PID: 6861 Comm: bash Kdump: loaded Not tainted 6.19.0-devel #3 PREEMPTLAZY
Hardware name: IBM 9175 ME1 701 (LPAR)
Call Trace:
[<000001a194837ec2>] dump_stack_lvl+0xa2/0xe8
[<000001a194942166>] __lock_acquire+0x816/0x1660
[<000001a1949431fa>] lock_acquire+0x24a/0x370
[<000001a19596b810>] _raw_spin_lock_irqsave+0x70/0xc0
[<000001a194843b6c>] debug_event_common+0xfc/0x300
[<000001a194888b0a>] __zpci_load+0x17a/0x1f0
[<000001a194882d88>] pci_read+0x88/0xd0
[<000001a195453b88>] pci_bus_read_config_byte+0x68/0xa0
[<000001a195457bc2>] pci_setup_device+0x62/0xad0
[<000001a195458e70>] pci_scan_single_device+0x90/0xe0
[<000001a19488a0f6>] zpci_bus_scan_device+0x46/0x80
[<000001a19547f958>] enable_slot+0x98/0xc0
[<000001a19547f134>] power_write_file+0xc4/0x110
[<000001a194e20758>] kernfs_fop_write_iter+0x1e8/0x260
[<000001a194d215da>] new_sync_write+0x13a/0x180
[<000001a194d245d0>] vfs_write+0x200/0x330
[<000001a194d2488c>] ksys_write+0x7c/0xf0
[<000001a195957a30>] __do_syscall+0x210/0x500
[<000001a19596cbb6>] system_call+0x6e/0x90
INFO: lockdep is turned off.
Since it is desired to keep it possible to create trace records in most
situations, including this particular case (failing PCI config space
accesses are relevant), convert the used spinlock_t in `struct
debug_info` to raw_spinlock_t.
The impact is small, as the debug area lock only protects bounded memory
access without external dependencies, apart from one function
debug_set_size() where kfree() is implicitly called with the lock held.
Move debug_info_free() out of this lock, to keep remove this external
dependency.
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
rafaeljw
pushed a commit
that referenced
this pull request
Feb 28, 2026
…oad_from_user_allowed() cxl_payload_from_user_allowed() casts and dereferences the input payload without first verifying its size. When a raw mailbox command is sent with an undersized payload (ie: 1 byte for CXL_MBOX_OP_CLEAR_LOG, which expects a 16-byte UUID), uuid_equal() reads past the allocated buffer, triggering a KASAN splat: BUG: KASAN: slab-out-of-bounds in memcmp+0x176/0x1d0 lib/string.c:683 Read of size 8 at addr ffff88810130f5c0 by task syz.1.62/2258 CPU: 2 UID: 0 PID: 2258 Comm: syz.1.62 Not tainted 6.19.0-dirty #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xab/0xe0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x650 mm/kasan/report.c:482 kasan_report+0xce/0x100 mm/kasan/report.c:595 memcmp+0x176/0x1d0 lib/string.c:683 uuid_equal include/linux/uuid.h:73 [inline] cxl_payload_from_user_allowed drivers/cxl/core/mbox.c:345 [inline] cxl_mbox_cmd_ctor drivers/cxl/core/mbox.c:368 [inline] cxl_validate_cmd_from_user drivers/cxl/core/mbox.c:522 [inline] cxl_send_cmd+0x9c0/0xb50 drivers/cxl/core/mbox.c:643 __cxl_memdev_ioctl drivers/cxl/core/memdev.c:698 [inline] cxl_memdev_ioctl+0x14f/0x190 drivers/cxl/core/memdev.c:713 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa8/0x330 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdaf331ba79 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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:00007fdaf1d77038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fdaf3585fa0 RCX: 00007fdaf331ba79 RDX: 00002000000001c0 RSI: 00000000c030ce02 RDI: 0000000000000003 RBP: 00007fdaf33749df R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fdaf3586038 R14: 00007fdaf3585fa0 R15: 00007ffced2af768 </TASK> Add 'in_size' parameter to cxl_payload_from_user_allowed() and validate the payload is large enough. Fixes: 6179045 ("cxl/mbox: Block immediate mode in SET_PARTITION_INFO command") Fixes: 206f9fa ("cxl/mbox: Add Clear Log mailbox command") Signed-off-by: Davidlohr Bueso <dave@stgolabs.net> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Dave Jiang <dave.jiang@intel.com> Link: https://patch.msgid.link/20260220001618.963490-2-dave@stgolabs.net Signed-off-by: Dave Jiang <dave.jiang@intel.com>
rafaeljw
pushed a commit
that referenced
this pull request
Mar 1, 2026
test_progs run with ASAN reported [1]:
==126==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 32 byte(s) in 1 object(s) allocated from:
#0 0x7f1ff3cfa340 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x5610c15bb520 in bpf_program_attach_fd /codebuild/output/src685977285/src/actions-runner/_work/vmtest/vmtest/src/tools/lib/bpf/libbpf.c:13164
#2 0x5610c15bb740 in bpf_program__attach_xdp /codebuild/output/src685977285/src/actions-runner/_work/vmtest/vmtest/src/tools/lib/bpf/libbpf.c:13204
#3 0x5610c14f91d3 in test_xdp_flowtable /codebuild/output/src685977285/src/actions-runner/_work/vmtest/vmtest/src/tools/testing/selftests/bpf/prog_tests/xdp_flowtable.c:138
#4 0x5610c1533566 in run_one_test /codebuild/output/src685977285/src/actions-runner/_work/vmtest/vmtest/src/tools/testing/selftests/bpf/test_progs.c:1406
#5 0x5610c1537fb0 in main /codebuild/output/src685977285/src/actions-runner/_work/vmtest/vmtest/src/tools/testing/selftests/bpf/test_progs.c:2097
#6 0x7f1ff25df1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb)
#7 0x7f1ff25df28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 8e9fd827446c24067541ac5390e6f527fb5947bb)
#8 0x5610c0bd3180 in _start (/tmp/work/vmtest/vmtest/selftests/bpf/test_progs+0x593180) (BuildId: cdf9f103f42307dc0a2cd6cfc8afcbc1366cf8bd)
Fix by properly destroying bpf_link on exit in xdp_flowtable test.
[1] https://github.com/kernel-patches/vmtest/actions/runs/22361085418/job/64716490680
Signed-off-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
Link: https://lore.kernel.org/r/20260225003351.465104-1-ihor.solodrai@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
rafaeljw
pushed a commit
that referenced
this pull request
Mar 2, 2026
Lockdep found a bug in the event scheduling when a pinned event was failed and wakes up the threads in the ring buffer like below. It seems it should not grab a wait-queue lock under perf-context lock. Let's do it with irq_work. [ 39.913691] ============================= [ 39.914157] [ BUG: Invalid wait context ] [ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted [ 39.915271] ----------------------------- [ 39.915731] repro/837 is trying to lock: [ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, at: __wake_up+0x26/0x60 [ 39.917182] other info that might help us debug this: [ 39.917761] context-{5:5} [ 39.918079] 4 locks held by repro/837: [ 39.918530] #0: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: __perf_event_task_sched_in+0xd1/0xbc0 [ 39.919612] #1: ffff88806ca3c6f8 (&cpuctx_lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1a7/0xbc0 [ 39.920748] #2: ffff88800d91fc18 (&ctx->lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1f9/0xbc0 [ 39.921819] #3: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: perf_event_wakeup+0x6c/0x470 Fixes: f4b07fd ("perf/core: Use POLLHUP for a pinned event in error") Closes: https://lore.kernel.org/lkml/aD2w50VDvGIH95Pf@ly-workstation Reported-by: "Lai, Yi" <yi1.lai@linux.intel.com> Signed-off-by: Namhyung Kim <namhyung@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Tested-by: "Lai, Yi" <yi1.lai@linux.intel.com> Link: https://patch.msgid.link/20250603045105.1731451-1-namhyung@kernel.org
rafaeljw
pushed a commit
that referenced
this pull request
Mar 4, 2026
The current cpuset partition code is able to dynamically update the sched domains of a running system and the corresponding HK_TYPE_DOMAIN housekeeping cpumask to perform what is essentially the "isolcpus=domain,..." boot command line feature at run time. The housekeeping cpumask update requires flushing a number of different workqueues which may not be safe with cpus_read_lock() held as the workqueue flushing code may acquire cpus_read_lock() or acquiring locks which have locking dependency with cpus_read_lock() down the chain. Below is an example of such circular locking problem. ====================================================== WARNING: possible circular locking dependency detected 6.18.0-test+ #2 Tainted: G S ------------------------------------------------------ test_cpuset_prs/10971 is trying to acquire lock: ffff888112ba4958 ((wq_completion)sync_wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x7a/0x180 but task is already holding lock: ffffffffae47f450 (cpuset_mutex){+.+.}-{4:4}, at: cpuset_partition_write+0x85/0x130 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (cpuset_mutex){+.+.}-{4:4}: -> #3 (cpu_hotplug_lock){++++}-{0:0}: -> #2 (rtnl_mutex){+.+.}-{4:4}: -> #1 ((work_completion)(&arg.work)){+.+.}-{0:0}: -> #0 ((wq_completion)sync_wq){+.+.}-{0:0}: Chain exists of: (wq_completion)sync_wq --> cpu_hotplug_lock --> cpuset_mutex 5 locks held by test_cpuset_prs/10971: #0: ffff88816810e440 (sb_writers#7){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8891ab620890 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x260/0x5f0 #2: ffff8890a78b83e8 (kn->active#187){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x2b6/0x5f0 #3: ffffffffadf32900 (cpu_hotplug_lock){++++}-{0:0}, at: cpuset_partition_write+0x77/0x130 #4: ffffffffae47f450 (cpuset_mutex){+.+.}-{4:4}, at: cpuset_partition_write+0x85/0x130 Call Trace: <TASK> : touch_wq_lockdep_map+0x93/0x180 __flush_workqueue+0x111/0x10b0 housekeeping_update+0x12d/0x2d0 update_parent_effective_cpumask+0x595/0x2440 update_prstate+0x89d/0xce0 cpuset_partition_write+0xc5/0x130 cgroup_file_write+0x1a5/0x680 kernfs_fop_write_iter+0x3df/0x5f0 vfs_write+0x525/0xfd0 ksys_write+0xf9/0x1d0 do_syscall_64+0x95/0x520 entry_SYSCALL_64_after_hwframe+0x76/0x7e To avoid such a circular locking dependency problem, we have to call housekeeping_update() without holding the cpus_read_lock() and cpuset_mutex. The current set of wq's flushed by housekeeping_update() may not have work functions that call cpus_read_lock() directly, but we are likely to extend the list of wq's that are flushed in the future. Moreover, the current set of work functions may hold locks that may have cpu_hotplug_lock down the dependency chain. So housekeeping_update() is now called after releasing cpus_read_lock and cpuset_mutex at the end of a cpuset operation. These two locks are then re-acquired later before calling rebuild_sched_domains_locked(). To enable mutual exclusion between the housekeeping_update() call and other cpuset control file write actions, a new top level cpuset_top_mutex is introduced. This new mutex will be acquired first to allow sharing variables used by both code paths. However, cpuset update from CPU hotplug can still happen in parallel with the housekeeping_update() call, though that should be rare in production environment. As cpus_read_lock() is now no longer held when tmigr_isolated_exclude_cpumask() is called, it needs to acquire it directly. The lockdep_is_cpuset_held() is also updated to return true if either cpuset_top_mutex or cpuset_mutex is held. Fixes: 03ff735 ("cpuset: Update HK_TYPE_DOMAIN cpumask from cpuset") Signed-off-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps urllib3 from 2.0.7 to 2.2.2.
Release notes
Sourced from urllib3's releases.
... (truncated)
Changelog
Sourced from urllib3's changelog.
Commits
27e2a5cRelease 2.2.2 (#3406)accff72Merge pull request from GHSA-34jh-p97f-mpxf34be4a5Pin CFFI to a new release candidate instead of a Git commit (#3398)da41058Bump browser-actions/setup-chrome from 1.6.0 to 1.7.1 (#3399)b07a669Bump github/codeql-action from 2.13.4 to 3.25.6 (#3396)b8589ecMeasure coverage with v4 of artifact actions (#3394)f3bdc55Allow triggering CI manually (#3391)5239265Fix HTTP version in debug log (#3316)b34619fBump actions/checkout to 4.1.4 (#3387)9961d14Bump browser-actions/setup-chrome from 1.5.0 to 1.6.0 (#3386)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)You can disable automated security fix PRs for this repo from the Security Alerts page.