6.12.25-rc1 review
Subsystems (7)
Greg Kroah-Hartman
maintainerPATCH 143/223 platform/x86: amd: pmf: Fix STT limits
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit fcf27a6a926fd9eeba39e9c3fde43c9298fe284e upstream.
On some platforms it has been observed that STT limits are not being applied properly causing poor performance as power limits are set too low.
STT limits that are sent to the platform are supposed to be in Q8.8 format. Convert them before sending.
--- drivers/platform/x86/amd/pmf/auto-mode.c | 4 ++-- drivers/platform/x86/amd/pmf/cnqf.c | 8 ++++---- drivers/platform/x86/amd/pmf/core.c | 14 ++++++++++++++ drivers/platform/x86/amd/pmf/pmf.h | 1 + drivers/platform/x86/amd/pmf/sps.c | 12 ++++++++---- drivers/platform/x86/amd/pmf/tee-if.c | 6 ++++-- 6 files changed, 33 insertions(+), 12 deletions(-)
drivers/platform/x86/amd/pmf/auto-mode.c +2 -2
@@ -120,9 +120,9 @@ static void amd_pmf_set_automode(structamd_pmf_send_cmd (dev,SET_SPPT_APU_ONLY , false, pwr_ctrl->sppt_apu_only,NULL );amd_pmf_send_cmd (dev,SET_STT_MIN_LIMIT , false, pwr_ctrl->stt_min,NULL );amd_pmf_send_cmd (dev,SET_STT_LIMIT_APU , false, - pwr_ctrl->stt_skin_temp[STT_TEMP_APU ],NULL ); +fixp_q88_fromint (pwr_ctrl->stt_skin_temp[STT_TEMP_APU ]),NULL );amd_pmf_send_cmd (dev,SET_STT_LIMIT_HS2 , false, - pwr_ctrl->stt_skin_temp[STT_TEMP_HS2 ],NULL ); +fixp_q88_fromint (pwr_ctrl->stt_skin_temp[STT_TEMP_HS2 ]),NULL );if (is_apmf_func_supported (dev,APMF_FUNC_SET_FAN_IDX )) apmf_update_fan_idx(dev, config_store.mode_set[idx].fan_control.manual,
drivers/platform/x86/amd/pmf/cnqf.c +4 -4
@@ -81,10 +81,10 @@ static int amd_pmf_set_cnqf(struct amd_pamd_pmf_send_cmd (dev,SET_SPPT , false, pc->sppt,NULL );amd_pmf_send_cmd (dev,SET_SPPT_APU_ONLY , false, pc->sppt_apu_only,NULL );amd_pmf_send_cmd (dev,SET_STT_MIN_LIMIT , false, pc->stt_min,NULL ); -amd_pmf_send_cmd (dev,SET_STT_LIMIT_APU , false, pc->stt_skin_temp[STT_TEMP_APU ], -NULL ); -amd_pmf_send_cmd (dev,SET_STT_LIMIT_HS2 , false, pc->stt_skin_temp[STT_TEMP_HS2 ], -NULL ); +amd_pmf_send_cmd (dev,SET_STT_LIMIT_APU , false, +fixp_q88_fromint (pc->stt_skin_temp[STT_TEMP_APU ]),NULL ); +amd_pmf_send_cmd (dev,SET_STT_LIMIT_HS2 , false, +fixp_q88_fromint (pc->stt_skin_temp[STT_TEMP_HS2 ]),NULL );if (is_apmf_func_supported (dev,APMF_FUNC_SET_FAN_IDX )) apmf_update_fan_idx(dev,
drivers/platform/x86/amd/pmf/core.c +14 -0
@@ -176,6 +176,20 @@ static void __maybe_unused amd_pmf_dump_dev_dbg (dev->dev,"AMD_PMF_REGISTER_MESSAGE:%x\n" , value); } +/** +* fixp_q88_fromint: Convert integer to Q8.8 +* @val: input value +* +* Converts an integer into binary fixed point format where 8 bits +* are used for integer and 8 bits are used for the decimal. +* +* Return: unsigned integer converted to Q8.8 format +*/ +u32 fixp_q88_fromint (u32 val) +{ +return val <<8 ; +} +int amd_pmf_send_cmd (struct amd_pmf_dev *dev,u8 message,bool get,u32 arg,u32 *data) {int rc;
drivers/platform/x86/amd/pmf/pmf.h +1 -0
@@ -746,6 +746,7 @@ int apmf_install_handler(struct amd_pmf_int apmf_os_power_slider_update (struct amd_pmf_dev *dev,u8 flag);int amd_pmf_set_dram_addr (struct amd_pmf_dev *dev,bool alloc_buffer);int amd_pmf_notify_sbios_heartbeat_event_v2 (struct amd_pmf_dev *dev,u8 flag); +u32 fixp_q88_fromint (u32 val);/* SPS Layer */ int amd_pmf_get_pprof_modes (struct amd_pmf_dev *pmf);
drivers/platform/x86/amd/pmf/sps.c +8 -4
@@ -198,9 +198,11 @@ static void amd_pmf_update_slider_v2(stramd_pmf_send_cmd (dev,SET_STT_MIN_LIMIT , false, apts_config_store.val[idx].stt_min_limit,NULL );amd_pmf_send_cmd (dev,SET_STT_LIMIT_APU , false, - apts_config_store.val[idx].stt_skin_temp_limit_apu,NULL ); +fixp_q88_fromint (apts_config_store.val[idx].stt_skin_temp_limit_apu), +NULL );amd_pmf_send_cmd (dev,SET_STT_LIMIT_HS2 , false, - apts_config_store.val[idx].stt_skin_temp_limit_hs2,NULL ); +fixp_q88_fromint (apts_config_store.val[idx].stt_skin_temp_limit_hs2), +NULL ); } void amd_pmf_update_slider(struct amd_pmf_dev *dev, bool op, int idx,
@@ -217,9 +219,11 @@ void amd_pmf_update_slider(struct amd_pmamd_pmf_send_cmd (dev,SET_STT_MIN_LIMIT , false, config_store.prop[src][idx].stt_min,NULL );amd_pmf_send_cmd (dev,SET_STT_LIMIT_APU , false, - config_store.prop[src][idx].stt_skin_temp[STT_TEMP_APU ],NULL ); +fixp_q88_fromint (config_store.prop[src][idx].stt_skin_temp[STT_TEMP_APU ]), +NULL );amd_pmf_send_cmd (dev,SET_STT_LIMIT_HS2 , false, - config_store.prop[src][idx].stt_skin_temp[STT_TEMP_HS2 ],NULL ); +fixp_q88_fromint (config_store.prop[src][idx].stt_skin_temp[STT_TEMP_HS2 ]), +NULL ); }else if (op ==SLIDER_OP_GET ) {amd_pmf_send_cmd (dev,GET_SPL , true,ARG_NONE , &table->prop[src][idx].spl);amd_pmf_send_cmd (dev,GET_FPPT , true,ARG_NONE , &table->prop[src][idx].fppt);
drivers/platform/x86/amd/pmf/tee-if.c +4 -2
@@ -123,7 +123,8 @@ static void amd_pmf_apply_policies(struccase PMF_POLICY_STT_SKINTEMP_APU :if (dev->prev_data->stt_skintemp_apu != val) { -amd_pmf_send_cmd (dev,SET_STT_LIMIT_APU , false, val,NULL ); +amd_pmf_send_cmd (dev,SET_STT_LIMIT_APU , false, +fixp_q88_fromint (val),NULL );dev_dbg (dev->dev,"update STT_SKINTEMP_APU: %u\n" , val); dev->prev_data->stt_skintemp_apu = val; }
@@ -131,7 +132,8 @@ static void amd_pmf_apply_policies(struccase PMF_POLICY_STT_SKINTEMP_HS2 :if (dev->prev_data->stt_skintemp_hs2 != val) { -amd_pmf_send_cmd (dev,SET_STT_LIMIT_HS2 , false, val,NULL ); +amd_pmf_send_cmd (dev,SET_STT_LIMIT_HS2 , false, +fixp_q88_fromint (val),NULL );dev_dbg (dev->dev,"update STT_SKINTEMP_HS2: %u\n" , val); dev->prev_data->stt_skintemp_hs2 = val; }
Greg Kroah-Hartman
maintainerPATCH 144/223 perf/x86/intel: Allow to update user space GPRs from PEBS records
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dapeng Mi <[email protected]>
commit 71dcc11c2cd9e434c34a63154ecadca21c135ddd upstream.
Currently when a user samples user space GPRs (--user-regs option) with PEBS, the user space GPRs actually always come from software PMI instead of from PEBS hardware. This leads to the sampled GPRs to possibly be inaccurate for single PEBS record case because of the skid between counter overflow and GPRs sampling on PMI.
For the large PEBS case, it is even worse. If user sets the exclude_kernel attribute, large PEBS would be used to sample user space GPRs, but since PEBS GPRs group is not really enabled, it leads to all samples in the large PEBS record to share the same piece of user space GPRs, like this reproducer shows:
$ perf record -e branches:pu --user-regs=ip,ax -c 100000 ./foo $ perf report -D | grep "AX"
.... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead .... AX 0x000000003a0d4ead
So enable GPRs group for user space GPRs sampling and prioritize reading GPRs from PEBS. If the PEBS sampled GPRs is not user space GPRs (single PEBS record case), perf_sample_regs_user() modifies them to user space GPRs.
[ mingo: Clarified the changelog. ]
--- arch/x86/events/intel/ds.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
arch/x86/events/intel/ds.c +5 -3
@@ -1317,8 +1317,10 @@ static u64 pebs_update_adaptive_cfg(stru* + precise_ip < 2 for the non event IP * + For RTM TSX weight we need GPRs for the abort code. */ - gprs = (sample_type &PERF_SAMPLE_REGS_INTR ) && - (attr->sample_regs_intr &PEBS_GP_REGS ); + gprs = ((sample_type &PERF_SAMPLE_REGS_INTR ) && + (attr->sample_regs_intr &PEBS_GP_REGS )) || + ((sample_type &PERF_SAMPLE_REGS_USER ) && + (attr->sample_regs_user &PEBS_GP_REGS )); tsx_weight = (sample_type & PERF_SAMPLE_WEIGHT_TYPE) && ((attr->config & INTEL_ARCH_EVENT_MASK) ==
@@ -1970,7 +1972,7 @@ static void setup_pebs_adaptive_sample_d regs->flags &= ~PERF_EFLAGS_EXACT ; } -if (sample_type &PERF_SAMPLE_REGS_INTR ) +if (sample_type & (PERF_SAMPLE_REGS_INTR |PERF_SAMPLE_REGS_USER ))adaptive_pebs_save_regs (regs, gprs); }
Greg Kroah-Hartman
maintainerPATCH 145/223 perf/x86/intel/uncore: Fix the scale of IIO free running counters on SNR
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
commit 96a720db59ab330c8562b2437153faa45dac705f upstream.
There was a mistake in the SNR uncore spec. The counter increments for every 32 bytes of data sent from the IO agent to the SOC, not 4 bytes which was documented in the spec.
The event list has been updated:
"EventName": "UNC_IIO_BANDWIDTH_IN.PART0_FREERUN", "BriefDescription": "Free running counter that increments for every 32
bytes of data sent from the IO agent to the SOC",
Update the scale of the IIO bandwidth in free running counters as well.
--- arch/x86/events/intel/uncore_snbep.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
arch/x86/events/intel/uncore_snbep.c +8 -8
@@ -4891,28 +4891,28 @@ static struct uncore_event_desc snr_uncoINTEL_UNCORE_EVENT_DESC (ioclk,"event=0xff,umask=0x10" ),/* Free-Running IIO BANDWIDTH IN Counters */ INTEL_UNCORE_EVENT_DESC (bw_in_port0,"event=0xff,umask=0x20" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port0.scale,"3.814697266e-6" ), +INTEL_UNCORE_EVENT_DESC (bw_in_port0.scale,"3.0517578125e-5" ),INTEL_UNCORE_EVENT_DESC (bw_in_port0.unit,"MiB" ),INTEL_UNCORE_EVENT_DESC (bw_in_port1,"event=0xff,umask=0x21" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port1.scale,"3.814697266e-6" ), +INTEL_UNCORE_EVENT_DESC (bw_in_port1.scale,"3.0517578125e-5" ),INTEL_UNCORE_EVENT_DESC (bw_in_port1.unit,"MiB" ),INTEL_UNCORE_EVENT_DESC (bw_in_port2,"event=0xff,umask=0x22" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port2.scale,"3.814697266e-6" ), +INTEL_UNCORE_EVENT_DESC (bw_in_port2.scale,"3.0517578125e-5" ),INTEL_UNCORE_EVENT_DESC (bw_in_port2.unit,"MiB" ),INTEL_UNCORE_EVENT_DESC (bw_in_port3,"event=0xff,umask=0x23" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port3.scale,"3.814697266e-6" ), +INTEL_UNCORE_EVENT_DESC (bw_in_port3.scale,"3.0517578125e-5" ),INTEL_UNCORE_EVENT_DESC (bw_in_port3.unit,"MiB" ),INTEL_UNCORE_EVENT_DESC (bw_in_port4,"event=0xff,umask=0x24" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port4.scale,"3.814697266e-6" ), +INTEL_UNCORE_EVENT_DESC (bw_in_port4.scale,"3.0517578125e-5" ),INTEL_UNCORE_EVENT_DESC (bw_in_port4.unit,"MiB" ),INTEL_UNCORE_EVENT_DESC (bw_in_port5,"event=0xff,umask=0x25" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port5.scale,"3.814697266e-6" ), +INTEL_UNCORE_EVENT_DESC (bw_in_port5.scale,"3.0517578125e-5" ),INTEL_UNCORE_EVENT_DESC (bw_in_port5.unit,"MiB" ),INTEL_UNCORE_EVENT_DESC (bw_in_port6,"event=0xff,umask=0x26" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port6.scale,"3.814697266e-6" ), +INTEL_UNCORE_EVENT_DESC (bw_in_port6.scale,"3.0517578125e-5" ),INTEL_UNCORE_EVENT_DESC (bw_in_port6.unit,"MiB" ),INTEL_UNCORE_EVENT_DESC (bw_in_port7,"event=0xff,umask=0x27" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port7.scale,"3.814697266e-6" ), +INTEL_UNCORE_EVENT_DESC (bw_in_port7.scale,"3.0517578125e-5" ), INTEL_UNCORE_EVENT_DESC(bw_in_port7.unit, "MiB"), { /* end: all zeroes */ }, };
Greg Kroah-Hartman
maintainerPATCH 146/223 perf/x86/intel/uncore: Fix the scale of IIO free running counters on ICX
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
commit 32c7f1150225694d95a51110a93be25db03bb5db upstream.
There was a mistake in the ICX uncore spec too. The counter increments for every 32 bytes rather than 4 bytes.
The same as SNR, there are 1 ioclk and 8 IIO bandwidth in free running counters. Reuse the snr_uncore_iio_freerunning_events().
--- arch/x86/events/intel/uncore_snbep.c | 33 +-------------------------------- 1 file changed, 1 insertion(+), 32 deletions(-)
arch/x86/events/intel/uncore_snbep.c +1 -32
@@ -5485,37 +5485,6 @@ static struct freerunning_counters icx_i [ICX_IIO_MSR_BW_IN] = { 0xaa0, 0x1, 0x10, 8, 48, icx_iio_bw_freerunning_box_offsets }, }; -static struct uncore_event_desc icx_uncore_iio_freerunning_events[] = { -/* Free-Running IIO CLOCKS Counter */ -INTEL_UNCORE_EVENT_DESC (ioclk,"event=0xff,umask=0x10" ), -/* Free-Running IIO BANDWIDTH IN Counters */ -INTEL_UNCORE_EVENT_DESC (bw_in_port0,"event=0xff,umask=0x20" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port0.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port0.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port1,"event=0xff,umask=0x21" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port1.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port1.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port2,"event=0xff,umask=0x22" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port2.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port2.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port3,"event=0xff,umask=0x23" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port3.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port3.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port4,"event=0xff,umask=0x24" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port4.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port4.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port5,"event=0xff,umask=0x25" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port5.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port5.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port6,"event=0xff,umask=0x26" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port6.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port6.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port7,"event=0xff,umask=0x27" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port7.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port7.unit,"MiB" ), - {/* end: all zeroes */ }, -}; -static struct intel_uncore_type icx_uncore_iio_free_running = { .name ="iio_free_running" , .num_counters =9 ,
@@ -5523,7 +5492,7 @@ static struct intel_uncore_type icx_unco .num_freerunning_types = ICX_IIO_FREERUNNING_TYPE_MAX, .freerunning = icx_iio_freerunning, .ops = &skx_uncore_iio_freerunning_ops, - .event_descs = icx_uncore_iio_freerunning_events, + .event_descs = snr_uncore_iio_freerunning_events, .format_group = &skx_uncore_iio_freerunning_format_group, };
Greg Kroah-Hartman
maintainerPATCH 147/223 perf/x86/intel/uncore: Fix the scale of IIO free running counters on SPR
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kan Liang <[email protected]>
commit 506f981ab40f0b03a11a640cfd77f48b09aff330 upstream.
The scale of IIO bandwidth in free running counters is inherited from the ICX. The counter increments for every 32 bytes rather than 4 bytes.
The IIO bandwidth out free running counters don't increment with a consistent size. The increment depends on the requested size. It's impossible to find a fixed increment. Remove it from the event_descs.
--- arch/x86/events/intel/uncore_snbep.c | 58 ----------------------------------- 1 file changed, 1 insertion(+), 57 deletions(-)
arch/x86/events/intel/uncore_snbep.c +1 -57
@@ -6289,69 +6289,13 @@ static struct freerunning_counters spr_i [SPR_IIO_MSR_BW_OUT] = { 0x3808, 0x1, 0x10, 8, 48 }, }; -static struct uncore_event_desc spr_uncore_iio_freerunning_events[] = { -/* Free-Running IIO CLOCKS Counter */ -INTEL_UNCORE_EVENT_DESC (ioclk,"event=0xff,umask=0x10" ), -/* Free-Running IIO BANDWIDTH IN Counters */ -INTEL_UNCORE_EVENT_DESC (bw_in_port0,"event=0xff,umask=0x20" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port0.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port0.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port1,"event=0xff,umask=0x21" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port1.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port1.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port2,"event=0xff,umask=0x22" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port2.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port2.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port3,"event=0xff,umask=0x23" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port3.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port3.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port4,"event=0xff,umask=0x24" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port4.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port4.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port5,"event=0xff,umask=0x25" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port5.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port5.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port6,"event=0xff,umask=0x26" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port6.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port6.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port7,"event=0xff,umask=0x27" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port7.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_in_port7.unit,"MiB" ), -/* Free-Running IIO BANDWIDTH OUT Counters */ -INTEL_UNCORE_EVENT_DESC (bw_out_port0,"event=0xff,umask=0x30" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port0.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port0.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port1,"event=0xff,umask=0x31" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port1.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port1.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port2,"event=0xff,umask=0x32" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port2.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port2.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port3,"event=0xff,umask=0x33" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port3.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port3.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port4,"event=0xff,umask=0x34" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port4.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port4.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port5,"event=0xff,umask=0x35" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port5.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port5.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port6,"event=0xff,umask=0x36" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port6.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port6.unit,"MiB" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port7,"event=0xff,umask=0x37" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port7.scale,"3.814697266e-6" ), -INTEL_UNCORE_EVENT_DESC (bw_out_port7.unit,"MiB" ), - {/* end: all zeroes */ }, -}; -static struct intel_uncore_type spr_uncore_iio_free_running = { .name ="iio_free_running" , .num_counters =17 , .num_freerunning_types =SPR_IIO_FREERUNNING_TYPE_MAX , .freerunning = spr_iio_freerunning, .ops = &skx_uncore_iio_freerunning_ops, - .event_descs = spr_uncore_iio_freerunning_events, + .event_descs = snr_uncore_iio_freerunning_events, .format_group = &skx_uncore_iio_freerunning_format_group, };
Greg Kroah-Hartman
maintainerPATCH 148/223 drm/repaper: fix integer overflows in repeat functions
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikita Zhandarovich <[email protected]>
commit 4d098000ac193f359e6b8ca4801dbdbd6a27b41f upstream.
There are conditions, albeit somewhat unlikely, under which right hand expressions, calculating the end of time period in functions like repaper_frame_fixed_repeat(), may overflow.
For instance, if 'factor10x' in repaper_get_temperature() is high enough (170), as is 'epd->stage_time' in repaper_probe(), then the resulting value of 'end' will not fit in unsigned int expression.
Mitigate this by casting 'epd->factored_stage_time' to wider type before any multiplication is done.
Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.
--- drivers/gpu/drm/tiny/repaper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/tiny/repaper.c +2 -2
@@ -455,7 +455,7 @@ static void repaper_frame_fixed_repeat(s enum repaper_stage stage) {u64 start =local_clock (); -u64 end = start + (epd->factored_stage_time *1000 *1000 ); +u64 end = start + ((u64 )epd->factored_stage_time *1000 *1000 ); do { repaper_frame_fixed(epd, fixed_value, stage);
@@ -466,7 +466,7 @@ static void repaper_frame_data_repeat(st const u8 *mask, enum repaper_stage stage) { u64 start = local_clock(); -u64 end = start + (epd->factored_stage_time *1000 *1000 ); +u64 end = start + ((u64 )epd->factored_stage_time *1000 *1000 ); do { repaper_frame_data(epd, image, mask, stage);
Greg Kroah-Hartman
maintainerPATCH 149/223 drm/ast: Fix ast_dp connection status
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jocelyn Falempe <[email protected]>
commit c28f72c6ca98e039c2aa5aac6752c416bc31dbab upstream.
ast_dp_is_connected() used to also check for link training success to report the DP connector as connected. Without this check, the physical_status is always connected. So if no monitor is present, it will fail to read the EDID and set the default resolution to 640x480 instead of 1024x768.
--- drivers/gpu/drm/ast/ast_dp.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/gpu/drm/ast/ast_dp.c +6 -0
@@ -17,6 +17,12 @@ static bool ast_astdp_is_connected(struct ast_device *ast) {if (!ast_get_index_reg_mask (ast,AST_IO_VGACRI ,0xDF ,AST_IO_VGACRDF_HPD ))return false; +/* +* HPD might be set even if no monitor is connected, so also check that +* the link training was successful. +*/ +if (!ast_get_index_reg_mask (ast,AST_IO_VGACRI ,0xDC ,AST_IO_VGACRDC_LINK_SUCCESS )) +return false;return true; }
Signature · 1 line
2.49.0
Greg Kroah-Hartman
maintainerPATCH 150/223 drm/msm/dsi: Add check for devm_kstrdup()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haoxiang Li <[email protected]>
commit 52b3f0e118b1700e5c60ff676a1f522ce44fadc8 upstream.
Add check for the return value of devm_kstrdup() in dsi_host_parse_dt() to catch potential exception.
Patchwork: https://patchwork.freedesktop.org/patch/638297/
--- drivers/gpu/drm/msm/dsi/dsi_host.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
drivers/gpu/drm/msm/dsi/dsi_host.c +8 -1
@@ -1827,8 +1827,15 @@ static int dsi_host_parse_dt(struct msm_ __func__, ret); goto err; } -if (!ret) +if (!ret) { msm_dsi->te_source =devm_kstrdup (dev, te_source,GFP_KERNEL ); +if (!msm_dsi->te_source) { +DRM_DEV_ERROR (dev,"%s: failed to allocate te_source\n" , + __func__); + ret = -ENOMEM ; + goto err; + } + } ret =0 ;if (of_property_read_bool (np,"syscon-sfpb" )) {
Greg Kroah-Hartman
maintainerPATCH 151/223 drm/msm/a6xx: Fix stale rpmh votes from GPU
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Akhil P Oommen <[email protected]>
commit f561db72a663f8a73c2250bf3244ce1ce221bed7 upstream.
It was observed on sc7180 (A618 gpu) that GPU votes for GX rail and CNOC BCM nodes were not removed after GPU suspend. This was because we skipped sending 'prepare-slumber' request to gmu during suspend sequence in some cases. So, make sure we always call prepare-slumber hfi during suspend. Also, calling prepare-slumber without a prior oob-gpu handshake messes up gmu firmware's internal state. So, do that when required.
Patchwork: https://patchwork.freedesktop.org/patch/639569/
--- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 82 ++++++++++++++++++---------------- 1 file changed, 44 insertions(+), 38 deletions(-)
drivers/gpu/drm/msm/adreno/a6xx_gmu.c +44 -38
@@ -1126,50 +1126,51 @@ static void a6xx_gmu_shutdown(struct a6x struct a6xx_gpu *a6xx_gpu = container_of(gmu, struct a6xx_gpu, gmu);struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;u32 val; +int ret;/* -* The GMU may still be in slumber unless the GPU started so check and -* skip putting it back into slumber if so +* GMU firmware's internal power state gets messed up if we send "prepare_slumber" hfi when +* oob_gpu handshake wasn't done after the last wake up. So do a dummy handshake here when +* required */ - val =gmu_read (gmu,REG_A6XX_GPU_GMU_CX_GMU_RPMH_POWER_STATE ); +if (adreno_gpu->base.needs_hw_init) { +if (a6xx_gmu_set_oob (&a6xx_gpu->gmu,GMU_OOB_GPU_SET )) + goto force_off; -if (val !=0xf ) { -int ret =a6xx_gmu_wait_for_idle (gmu); - -/* If the GMU isn't responding assume it is hung */ -if (ret) { -a6xx_gmu_force_off (gmu); -return ; - } - -a6xx_bus_clear_pending_transactions (adreno_gpu, a6xx_gpu->hung); - -/* tell the GMU we want to slumber */ - ret =a6xx_gmu_notify_slumber (gmu); -if (ret) { -a6xx_gmu_force_off (gmu); -return ; - } - - ret =gmu_poll_timeout (gmu, -REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS , val, - !(val &A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS_GPUBUSYIGNAHB ), -100 ,10000 ); - -/* -* Let the user know we failed to slumber but don't worry too -* much because we are powering down anyway -*/ - -if (ret) -DRM_DEV_ERROR (gmu->dev, -"Unable to slumber GMU: status = 0%x/0%x\n" , -gmu_read (gmu, -REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS ), -gmu_read (gmu, -REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS2 )); +a6xx_gmu_clear_oob (&a6xx_gpu->gmu,GMU_OOB_GPU_SET ); } + ret =a6xx_gmu_wait_for_idle (gmu); + +/* If the GMU isn't responding assume it is hung */ +if (ret) + goto force_off; + +a6xx_bus_clear_pending_transactions (adreno_gpu, a6xx_gpu->hung); + +/* tell the GMU we want to slumber */ + ret =a6xx_gmu_notify_slumber (gmu); +if (ret) + goto force_off; + + ret =gmu_poll_timeout (gmu, +REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS , val, + !(val &A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS_GPUBUSYIGNAHB ), +100 ,10000 ); + +/* +* Let the user know we failed to slumber but don't worry too +* much because we are powering down anyway +*/ + +if (ret) +DRM_DEV_ERROR (gmu->dev, +"Unable to slumber GMU: status = 0%x/0%x\n" , +gmu_read (gmu, +REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS ), +gmu_read (gmu, +REG_A6XX_GPU_GMU_AO_GPU_CX_BUSY_STATUS2 )); +/* Turn off HFI */ a6xx_hfi_stop (gmu);
@@ -1178,6 +1179,11 @@ static void a6xx_gmu_shutdown(struct a6x/* Tell RPMh to power off the GPU */ a6xx_rpmh_stop (gmu); + +return ; + +force_off: +a6xx_gmu_force_off (gmu); }
Greg Kroah-Hartman
maintainerPATCH 152/223 drm/amdgpu: Prefer shadow rom when available
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lijo Lazar <[email protected]>
commit 27145f78f56a3178c4f9ffe51c4406d8dd0ca90c upstream.
Fetch VBIOS from shadow ROM when available before trying other methods like EFI method.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 36 ++++++++++++++++++++++++------- 1 file changed, 28 insertions(+), 8 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c +28 -8
@@ -437,6 +437,13 @@ success:return true; } +static bool amdgpu_prefer_rom_resource (struct amdgpu_device *adev) +{ +struct resource *res = &adev->pdev->resource[PCI_ROM_RESOURCE ]; + +return (res->flags &IORESOURCE_ROM_SHADOW ); +} +static bool amdgpu_get_bios_dgpu (struct amdgpu_device *adev) {if (amdgpu_atrm_get_bios (adev)) {
@@ -455,14 +462,27 @@ static bool amdgpu_get_bios_dgpu(struct goto success; } -if (amdgpu_read_platform_bios (adev)) { -dev_info (adev->dev,"Fetched VBIOS from platform\n" ); - goto success; - } - -if (amdgpu_read_bios (adev)) { -dev_info (adev->dev,"Fetched VBIOS from ROM BAR\n" ); - goto success; +if (amdgpu_prefer_rom_resource (adev)) { +if (amdgpu_read_bios (adev)) { +dev_info (adev->dev,"Fetched VBIOS from ROM BAR\n" ); + goto success; + } + +if (amdgpu_read_platform_bios (adev)) { +dev_info (adev->dev,"Fetched VBIOS from platform\n" ); + goto success; + } + + }else { +if (amdgpu_read_platform_bios (adev)) { +dev_info (adev->dev,"Fetched VBIOS from platform\n" ); + goto success; + } + +if (amdgpu_read_bios (adev)) { +dev_info (adev->dev,"Fetched VBIOS from ROM BAR\n" ); + goto success; + } }if (amdgpu_read_bios_from_rom (adev)) {
Greg Kroah-Hartman
maintainerPATCH 153/223 drm/amd/display: prevent hang on link training fail
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brendan Tam <[email protected]>
commit 8058061ed9d6bc259d1e678607b07d259342c08f upstream.
[Why]
When link training fails, the phy clock will be disabled. However, in enable_streams, it is assumed that link training succeeded and the mux selects the phy clock, causing a hang when a register write is made.
[How]
When enable_stream is hit, check if link training failed. If it did, fall back to the ref clock to avoid a hang and keep the system in a recoverable state.
--- drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c | 6 +++++- drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c | 7 +++++-- 2 files changed, 10 insertions(+), 3 deletions(-)
drivers/gpu/drm/amd/display/dc/hwss/dcn20/dcn20_hwseq.c +5 -1
@@ -3003,7 +3003,11 @@ void dcn20_enable_stream(struct pipe_ctx dccg->funcs->set_dpstreamclk (dccg,DTBCLK0 , tg->inst, dp_hpo_inst); phyd32clk =get_phyd32clk_src (link); - dccg->funcs->enable_symclk32_se (dccg, dp_hpo_inst, phyd32clk); +if (link->cur_link_settings.link_rate ==LINK_RATE_UNKNOWN ) { + dccg->funcs->disable_symclk32_se (dccg, dp_hpo_inst); + }else { + dccg->funcs->enable_symclk32_se (dccg, dp_hpo_inst, phyd32clk); + } }else {if (dccg->funcs->enable_symclk_se) dccg->funcs->enable_symclk_se(dccg, stream_enc->stream_enc_inst,
drivers/gpu/drm/amd/display/dc/hwss/dcn401/dcn401_hwseq.c +5 -2
@@ -1001,8 +1001,11 @@ void dcn401_enable_stream(struct pipe_ctif (dc_is_dp_signal (pipe_ctx->stream->signal) ||dc_is_virtual_signal (pipe_ctx->stream->signal)) {if (dc->link_srv->dp_is_128b_132b_signal (pipe_ctx)) { dccg->funcs->set_dpstreamclk (dccg,DPREFCLK , tg->inst, dp_hpo_inst); - - dccg->funcs->enable_symclk32_se (dccg, dp_hpo_inst, phyd32clk); +if (link->cur_link_settings.link_rate ==LINK_RATE_UNKNOWN ) { + dccg->funcs->disable_symclk32_se (dccg, dp_hpo_inst); + }else { + dccg->funcs->enable_symclk32_se (dccg, dp_hpo_inst, phyd32clk); + } }else {/* need to set DTBCLK_P source to DPREFCLK for DP8B10B */ dccg->funcs->set_dtbclk_p_src (dccg,DPREFCLK , tg->inst);
Greg Kroah-Hartman
maintainerPATCH 154/223 drm/amd: Handle being compiled without SI or CIK support better
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit 5f054ddead33c1622ea9c0c0aaf07c6843fc7ab0 upstream.
If compiled without SI or CIK support but amdgpu tries to load it will run into failures with uninitialized callbacks.
Show a nicer message in this case and fail probe instead.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 44 +++++++++++++++++--------------- 1 file changed, 24 insertions(+), 20 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +24 -20
@@ -1795,7 +1795,6 @@ static const u16 amdgpu_unsupported_pcii };static const struct pci_device_id pciidlist[] = { -#ifdef CONFIG_DRM_AMDGPU_SI {0x1002 ,0x6780 ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 ,CHIP_TAHITI }, {0x1002 ,0x6784 ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 ,CHIP_TAHITI }, {0x1002 ,0x6788 ,PCI_ANY_ID ,PCI_ANY_ID ,0 ,0 ,CHIP_TAHITI },
@@ -1868,8 +1867,6 @@ static const struct pci_device_id pciidl {0x1002, 0x6665, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_HAINAN|AMD_IS_MOBILITY}, {0x1002, 0x6667, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_HAINAN|AMD_IS_MOBILITY}, {0x1002, 0x666F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_HAINAN|AMD_IS_MOBILITY}, -#endif -#ifdef CONFIG_DRM_AMDGPU_CIK/* Kaveri */ {0x1002, 0x1304, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_MOBILITY|AMD_IS_APU}, {0x1002, 0x1305, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_KAVERI|AMD_IS_APU},
@@ -1952,7 +1949,6 @@ static const struct pci_device_id pciidl {0x1002, 0x985D, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MULLINS|AMD_IS_MOBILITY|AMD_IS_APU}, {0x1002, 0x985E, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MULLINS|AMD_IS_MOBILITY|AMD_IS_APU}, {0x1002, 0x985F, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_MULLINS|AMD_IS_MOBILITY|AMD_IS_APU}, -#endif/* topaz */ {0x1002, 0x6900, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TOPAZ}, {0x1002, 0x6901, PCI_ANY_ID, PCI_ANY_ID, 0, 0, CHIP_TOPAZ},
@@ -2284,14 +2280,14 @@ static int amdgpu_pci_probe(struct pci_dreturn -ENOTSUPP ; } +switch (flags &AMD_ASIC_MASK ) { +case CHIP_TAHITI : +case CHIP_PITCAIRN : +case CHIP_VERDE : +case CHIP_OLAND : +case CHIP_HAINAN :#ifdef CONFIG_DRM_AMDGPU_SI -if (!amdgpu_si_support) { -switch (flags &AMD_ASIC_MASK ) { -case CHIP_TAHITI : -case CHIP_PITCAIRN : -case CHIP_VERDE : -case CHIP_OLAND : -case CHIP_HAINAN : +if (!amdgpu_si_support) {dev_info (&pdev->dev,"SI support provided by radeon.\n" ); dev_info(&pdev->dev,
@@ -2299,16 +2295,18 @@ static int amdgpu_pci_probe(struct pci_d );return -ENODEV ; } - } +break ; +#else +dev_info (&pdev->dev,"amdgpu is built without SI support.\n" ); +return -ENODEV ;#endif +case CHIP_KAVERI : +case CHIP_BONAIRE : +case CHIP_HAWAII : +case CHIP_KABINI : +case CHIP_MULLINS :#ifdef CONFIG_DRM_AMDGPU_CIK -if (!amdgpu_cik_support) { -switch (flags &AMD_ASIC_MASK ) { -case CHIP_KAVERI : -case CHIP_BONAIRE : -case CHIP_HAWAII : -case CHIP_KABINI : -case CHIP_MULLINS : +if (!amdgpu_cik_support) {dev_info (&pdev->dev,"CIK support provided by radeon.\n" ); dev_info(&pdev->dev,
@@ -2316,8 +2314,14 @@ static int amdgpu_pci_probe(struct pci_d ); return -ENODEV; } - } +break ; +#else +dev_info (&pdev->dev,"amdgpu is built without CIK support.\n" ); +return -ENODEV ;#endif +default : +break ; + } adev =devm_drm_dev_alloc (&pdev->dev, &amdgpu_kms_driver,typeof (*adev), ddev);if (IS_ERR (adev))
Greg Kroah-Hartman
maintainerPATCH 155/223 drm/amd/display: Actually do immediate vblank disable
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leo Li <[email protected]>
commit 704bc361e3a4ead1c0eb40acc255b636b788dc89 upstream.
[Why]
The vblank_config.offdelay field follows the same semantics as the drm_vblank_offdelay parameter. Setting it to 0 will never disable vblank.
[How]
Set offdelay to a positive number.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +2 -0
@@ -8473,6 +8473,8 @@ static void manage_dm_interrupts(struct config.offdelay_ms = offdelay ?:30 ; }else { +/* offdelay_ms = 0 will never disable vblank */ + config.offdelay_ms =1 ; config.disable_immediate = true; }
Greg Kroah-Hartman
maintainerPATCH 156/223 drm/amd/display: Increase vblank offdelay for PSR panels
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leo Li <[email protected]>
commit f21e6d149b49c92f9e68aa0c76033e1e13d9f5da upstream.
[Why]
Depending on when the HW latching event (vupdate) of double-buffered registers happen relative to the PSR SDP (signals panel psr enter/exit) deadline, and how bad the Panel clock has drifted since the last ALPM off event, there can be up to 3 frames of delay between sending the PSR exit cmd to DMUB fw, and when the panel starts displaying live frames. This can manifest as micro-stuttering when userspace commit patterns cause rapid toggling of the DRM vblank counter, since PSR enter/exit is hooked up to DRM vblank disable/enable respectively.
In the ideal world, the panel should present the live frame immediately on PSR exit cmd. But due to HW design and PSR limitations, immediate exit can only happen by chance, when:
1. PSR exit cmd is ack'd by FW before HW latching (vupdate) event, and
2. Panel's SDP deadline -- determined by it's PSR Start Delay in DPCD 71h -- is after the vupdate event. The PSR exit SDP can then be sent immediately after HW latches. Otherwise, we have to wait 1 frame. And
3. There is negligible drift between the panel's clock and source clock. Otherwise, there can be up to 1 frame of drift.
Note that this delay is not expected with Panel Replay.
[How]
Since PSR power savings can be quite substantial, and there are a lot of systems in the wild with PSR panels, It'll be nice to have a middle ground that balances user experience with power savings.
A simple way to achieve this is by extending the vblank offdelay, such that additional PSR exit delays will be less perceivable.
We can set:
20/100 * offdelay_ms = 3_frames_ms
=> offdelay_ms = 5 * 3_frames_ms
This ensures that 3_frames_ms will only be experienced as a 20% delay on top how long the panel has been static, and thus make the delay less perceivable.
If this ends up being too high of a percentage, it can be dropped further in a future change.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 39 ++++++++++++++++++---- 1 file changed, 32 insertions(+), 7 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +32 -7
@@ -8458,14 +8458,39 @@ static void manage_dm_interrupts(structint offdelay;if (acrtc_state) { -if (amdgpu_ip_version (adev,DCE_HWIP ,0 ) < -IP_VERSION (3 ,5 ,0 ) || - acrtc_state->stream->link->psr_settings.psr_version < -DC_PSR_VERSION_UNSUPPORTED || - !(adev->flags &AMD_IS_APU )) { - timing = &acrtc_state->stream->timing; + timing = &acrtc_state->stream->timing; -/* at least 2 frames */ +/* +* Depending on when the HW latching event of double-buffered +* registers happen relative to the PSR SDP deadline, and how +* bad the Panel clock has drifted since the last ALPM off +* event, there can be up to 3 frames of delay between sending +* the PSR exit cmd to DMUB fw, and when the panel starts +* displaying live frames. +* +* We can set: +* +* 20/100 * offdelay_ms = 3_frames_ms +* => offdelay_ms = 5 * 3_frames_ms +* +* This ensures that `3_frames_ms` will only be experienced as a +* 20% delay on top how long the display has been static, and +* thus make the delay less perceivable. +*/ +if (acrtc_state->stream->link->psr_settings.psr_version < +DC_PSR_VERSION_UNSUPPORTED ) { + offdelay =DIV64_U64_ROUND_UP ((u64 )5 *3 *10 * + timing->v_total * + timing->h_total, + timing->pix_clk_100hz); + config.offdelay_ms = offdelay ?:30 ; + }else if (amdgpu_ip_version (adev,DCE_HWIP ,0 ) < +IP_VERSION (3 ,5 ,0 ) || + !(adev->flags &AMD_IS_APU )) { +/* +* Older HW and DGPU have issues with instant off; +* use a 2 frame offdelay. +*/ offdelay = DIV64_U64_ROUND_UP((u64)20 * timing->v_total * timing->h_total,
Greg Kroah-Hartman
maintainerPATCH 157/223 drm/amd/pm: Prevent division by zero
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Denis Arefev <[email protected]>
commit 7d641c2b83275d3b0424127b2e0d2d0f7dd82aef upstream.
The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/gpu/drm/amd/pm/swsmu/smu11/arcturus_ppt.c +3 -0
@@ -1267,6 +1267,9 @@ static int arcturus_set_fan_speed_rpm(stuint32_t crystal_clock_freq =2500 ;uint32_t tach_period; +if (!speed || speed >UINT_MAX /8 ) +return -EINVAL ; + tach_period =60 * crystal_clock_freq *10000 / (8 * speed); WREG32_SOC15(THM, 0, mmCG_TACH_CTRL_ARCT, REG_SET_FIELD(RREG32_SOC15(THM, 0, mmCG_TACH_CTRL_ARCT),
Greg Kroah-Hartman
maintainerPATCH 158/223 drm/amd/pm/powerplay: Prevent division by zero
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Denis Arefev <[email protected]>
commit 4b8c3c0d17c07f301011e2908fecd2ebdcfe3d1c upstream.
The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega10_thermal.c +2 -2
@@ -307,10 +307,10 @@ int vega10_fan_ctrl_set_fan_speed_rpm(stint result =0 ;if (hwmgr->thermal_controller.fanInfo.bNoFan || - speed ==0 || + (!speed || speed >UINT_MAX /8 ) || (speed < hwmgr->thermal_controller.fanInfo.ulMinRPM) || (speed > hwmgr->thermal_controller.fanInfo.ulMaxRPM)) -return -1 ; +return -EINVAL ;if (PP_CAP (PHM_PlatformCaps_MicrocodeFanControl)) result =vega10_fan_ctrl_stop_smc_fan_control (hwmgr);
Greg Kroah-Hartman
maintainerPATCH 159/223 drm/amd/pm/smu11: Prevent division by zero
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Denis Arefev <[email protected]>
commit 7ba88b5cccc1a99c1afb96e31e7eedac9907704c upstream.
The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c +1 -1
@@ -1199,7 +1199,7 @@ int smu_v11_0_set_fan_speed_rpm(struct suint32_t crystal_clock_freq =2500 ;uint32_t tach_period; -if (speed ==0 ) +if (!speed || speed >UINT_MAX /8 )return -EINVAL ;/* * To prevent from possible overheat, some ASICs may have requirement
Greg Kroah-Hartman
maintainerPATCH 160/223 drm/amd/pm/powerplay/hwmgr/smu7_thermal: Prevent division by zero
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Denis Arefev <[email protected]>
commit 7c246a05df51c52fe0852ce56ba10c41e6ed1f39 upstream.
The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_thermal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu7_thermal.c +2 -2
@@ -267,10 +267,10 @@ int smu7_fan_ctrl_set_fan_speed_rpm(struif (hwmgr->thermal_controller.fanInfo.bNoFan || (hwmgr->thermal_controller.fanInfo. ucTachometerPulsesPerRevolution ==0 ) || - speed ==0 || + (!speed || speed >UINT_MAX /8 ) || (speed < hwmgr->thermal_controller.fanInfo.ulMinRPM) || (speed > hwmgr->thermal_controller.fanInfo.ulMaxRPM)) -return 0 ; +return -EINVAL ;if (PP_CAP (PHM_PlatformCaps_MicrocodeFanControl))smu7_fan_ctrl_stop_smc_fan_control (hwmgr);
Greg Kroah-Hartman
maintainerPATCH 161/223 drm/amd/pm/swsmu/smu13/smu_v13_0: Prevent division by zero
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Denis Arefev <[email protected]>
commit f23e9116ebb71b63fe9cec0dcac792aa9af30b0c upstream.
The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0.c +1 -1
@@ -1228,7 +1228,7 @@ int smu_v13_0_set_fan_speed_rpm(struct suint32_t tach_period;int ret; -if (!speed) +if (!speed || speed >UINT_MAX /8 )return -EINVAL ; ret =smu_v13_0_auto_fan_control (smu,0 );
Greg Kroah-Hartman
maintainerPATCH 162/223 drm/amd/pm/powerplay/hwmgr/vega20_thermal: Prevent division by zero
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Denis Arefev <[email protected]>
commit 4e3d9508c056d7e0a56b58d5c81253e2a0d22b6c upstream.
The user can set any speed value.
If speed is greater than UINT_MAX/8, division by zero is possible.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/pm/powerplay/hwmgr/vega20_thermal.c +1 -1
@@ -191,7 +191,7 @@ int vega20_fan_ctrl_set_fan_speed_rpm(stuint32_t tach_period, crystal_clock_freq;int result =0 ; -if (!speed) +if (!speed || speed >UINT_MAX /8 )return -EINVAL ;if (PP_CAP (PHM_PlatformCaps_MicrocodeFanControl)) {
Greg Kroah-Hartman
maintainerPATCH 163/223 drm/amdgpu/mes12: optimize MES pipe FW version fetching
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit 34779e14461cf715238dec5fd43a1e11977ec115 upstream.
Don't fetch it again if we already have it. It seems the registers don't reliably have the value at resume in some cases.
--- drivers/gpu/drm/amd/amdgpu/mes_v12_0.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-)
drivers/gpu/drm/amd/amdgpu/mes_v12_0.c +12 -9
@@ -1225,17 +1225,20 @@ static int mes_v12_0_queue_init(struct ames_v12_0_queue_init_register (ring); } -/* get MES scheduler/KIQ versions */ -mutex_lock (&adev->srbm_mutex); -soc21_grbm_select (adev,3 , pipe,0 ,0 ); +if (((pipe ==AMDGPU_MES_SCHED_PIPE ) && !adev->mes.sched_version) || + ((pipe ==AMDGPU_MES_KIQ_PIPE ) && !adev->mes.kiq_version)) { +/* get MES scheduler/KIQ versions */ +mutex_lock (&adev->srbm_mutex); +soc21_grbm_select (adev,3 , pipe,0 ,0 ); -if (pipe ==AMDGPU_MES_SCHED_PIPE ) - adev->mes.sched_version =RREG32_SOC15 (GC ,0 , regCP_MES_GP3_LO); -else if (pipe ==AMDGPU_MES_KIQ_PIPE && adev->enable_mes_kiq) - adev->mes.kiq_version =RREG32_SOC15 (GC ,0 , regCP_MES_GP3_LO); +if (pipe ==AMDGPU_MES_SCHED_PIPE ) + adev->mes.sched_version =RREG32_SOC15 (GC ,0 , regCP_MES_GP3_LO); +else if (pipe ==AMDGPU_MES_KIQ_PIPE && adev->enable_mes_kiq) + adev->mes.kiq_version =RREG32_SOC15 (GC ,0 , regCP_MES_GP3_LO); -soc21_grbm_select (adev,0 ,0 ,0 ,0 ); -mutex_unlock (&adev->srbm_mutex); +soc21_grbm_select (adev,0 ,0 ,0 ,0 ); +mutex_unlock (&adev->srbm_mutex); + }return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 164/223 drm/i915/vrr: Add vrr.vsync_{start, end} in vrr_params_changed
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ankit Nautiyal <[email protected]>
commit a421f5033c82990d795f8fcd30d5b835f8975508 upstream.
Add the missing vrr parameters in vrr_params_changed() helper. This ensures that changes in vrr.vsync_{start,end} trigger a call to appropriate helpers to update the VRR registers.
--- drivers/gpu/drm/i915/display/intel_display.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/gpu/drm/i915/display/intel_display.c +3 -1
@@ -1006,7 +1006,9 @@ static bool vrr_params_changed(const str old_crtc_state->vrr.vmin != new_crtc_state->vrr.vmin || old_crtc_state->vrr.vmax != new_crtc_state->vrr.vmax || old_crtc_state->vrr.guardband != new_crtc_state->vrr.guardband || - old_crtc_state->vrr.pipeline_full != new_crtc_state->vrr.pipeline_full; + old_crtc_state->vrr.pipeline_full != new_crtc_state->vrr.pipeline_full || + old_crtc_state->vrr.vsync_start != new_crtc_state->vrr.vsync_start || + old_crtc_state->vrr.vsync_end != new_crtc_state->vrr.vsync_end; } static bool cmrr_params_changed(const struct intel_crtc_state *old_crtc_state,
Greg Kroah-Hartman
maintainerPATCH 165/223 drm/xe: Use local fence in error path of xe_migrate_clear
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Brost <[email protected]>
commit 20659d3150f1a2a258a173fe011013178ff2a197 upstream.
The intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence.
--- drivers/gpu/drm/xe/xe_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/xe/xe_migrate.c +1 -1
@@ -1177,7 +1177,7 @@ err: err_sync:/* Sync partial copies if any. FIXME: job_mutex? */ if (fence) { -dma_fence_wait (m->fence, false); +dma_fence_wait (fence, false);dma_fence_put (fence); }
Greg Kroah-Hartman
maintainerPATCH 166/223 drm/amd/display: Add HP Elitebook 645 to the quirk list for eDP on DP1
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit 1c5fdef30ed120613e769a3bd2a144cfd4c688d6 upstream.
[Why]
HP Elitebook 645 has DP0 and DP1 swapped.
[How]
Add HP Elitebook 645 to DP0/DP1 swap quirk list.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +7 -0
@@ -1694,6 +1694,13 @@ static const struct dmi_system_id dmi_qu .callback = edp0_on_dp1_callback, .matches = {DMI_MATCH (DMI_SYS_VENDOR ,"HP" ), + DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 645 14 inch G11 Notebook PC"), + }, + }, + { + .callback = edp0_on_dp1_callback, + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"HP" ), DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 665 16 inch G11 Notebook PC"), }, },
Greg Kroah-Hartman
maintainerPATCH 167/223 drm/amd/display: Protect FPU in dml2_validate()/dml21_validate()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit 366e77cd4923c3aa45341e15dcaf3377af9b042f upstream.
Commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context start") removes the FP context protection of dml2_create(), and it said "All the DC_FP_START/END should be used before call anything from DML2".
However, dml2_validate()/dml21_validate() are not protected from their callers, causing such errors:
do_fpu invoked from kernel context![#1]:
CPU: 10 UID: 0 PID: 331 Comm: kworker/10:1H Not tainted 6.14.0-rc6+ #4
Workqueue: events_highpri dm_irq_work_func [amdgpu]
pc ffff800003191eb0 ra ffff800003191e60 tp 9000000107a94000 sp 9000000107a975b0
a0 9000000140ce4910 a1 0000000000000000 a2 9000000140ce49b0 a3 9000000140ce49a8
a4 9000000140ce49a8 a5 0000000100000000 a6 0000000000000001 a7 9000000107a97660
t0 ffff800003790000 t1 9000000140ce5000 t2 0000000000000001 t3 0000000000000000
t4 0000000000000004 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000
t8 0000000100000000 u0 ffff8000031a3b9c s9 9000000130bc0000 s0 9000000132400000
s1 9000000140ec0000 s2 9000000132400000 s3 9000000140ce0000 s4 90000000057f8b88
s5 9000000140ec0000 s6 9000000140ce4910 s7 0000000000000001 s8 9000000130d45010
ra: ffff800003191e60 dml21_map_dc_state_into_dml_display_cfg+0x40/0x1140 [amdgpu]
ERA: ffff800003191eb0 dml21_map_dc_state_into_dml_display_cfg+0x90/0x1140 [amdgpu]
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
PRMD: 00000004 (PPLV0 +PIE -PWE)
EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 000f0000 [FPD] (IS= ECode=15 EsubCode=0)
PRID: 0014d010 (Loongson-64bit, Loongson-3C6000/S)
Process kworker/10:1H (pid: 331, threadinfo=000000007bf9ddb0, task=00000000cc4ab9f3)
Stack : 0000000100000000 0000043800000780 0000000100000001 0000000100000001
0000000000000000 0000078000000000 0000000000000438 0000078000000000
0000000000000438 0000078000000000 0000000000000438 0000000100000000
0000000100000000 0000000100000000 0000000100000000 0000000100000000
0000000000000001 9000000140ec0000 9000000132400000 9000000132400000
ffff800003408000 ffff800003408000 9000000132400000 9000000140ce0000
9000000140ce0000 ffff800003193850 0000000000000001 9000000140ec0000
9000000132400000 9000000140ec0860 9000000140ec0738 0000000000000001
90000001405e8000 9000000130bc0000 9000000140ec02a8 ffff8000031b5db8
0000000000000000 0000043800000780 0000000000000003 ffff8000031b79cc
...
Call Trace:
[<ffff800003191eb0>] dml21_map_dc_state_into_dml_display_cfg+0x90/0x1140 [amdgpu]
[<ffff80000319384c>] dml21_validate+0xcc/0x520 [amdgpu]
[<ffff8000031b8948>] dc_validate_global_state+0x2e8/0x460 [amdgpu]
[<ffff800002e94034>] create_validate_stream_for_sink+0x3d4/0x420 [amdgpu]
[<ffff800002e940e4>] amdgpu_dm_connector_mode_valid+0x64/0x240 [amdgpu]
[<900000000441d6b8>] drm_connector_mode_valid+0x38/0x80
[<900000000441d824>] __drm_helper_update_and_validate+0x124/0x3e0
[<900000000441ddc0>] drm_helper_probe_single_connector_modes+0x2e0/0x620
[<90000000044050dc>] drm_client_modeset_probe+0x23c/0x1780
[<9000000004420384>] __drm_fb_helper_initial_config_and_unlock+0x44/0x5a0
[<9000000004403acc>] drm_client_dev_hotplug+0xcc/0x140
[<ffff800002e9ab50>] handle_hpd_irq_helper+0x1b0/0x1e0 [amdgpu]
[<90000000038f5da0>] process_one_work+0x160/0x300
[<90000000038f6718>] worker_thread+0x318/0x440
[<9000000003901b8c>] kthread+0x12c/0x220
[<90000000038b1484>] ret_from_kernel_thread+0x8/0xa4Unfortunately, protecting dml2_validate()/dml21_validate() out of DML2 causes "sleeping function called from invalid context", so protect them with DC_FP_START() and DC_FP_END() inside.
--- drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_wrapper.c | 9 +++++++-- drivers/gpu/drm/amd/display/dc/dml2/dml2_wrapper.c | 5 +++++ 2 files changed, 12 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_wrapper.c +7 -2
@@ -277,11 +277,16 @@ bool dml21_validate(const struct dc *in_ {bool out = false; +DC_FP_START (); +/* Use dml_validate_only for fast_validate path */ -if (fast_validate) { +if (fast_validate) out =dml21_check_mode_support (in_dc, context, dml_ctx); - }else +else out =dml21_mode_check_and_programming (in_dc, context, dml_ctx); + +DC_FP_END (); +return out; }
drivers/gpu/drm/amd/display/dc/dml2/dml2_wrapper.c +5 -0
@@ -734,11 +734,16 @@ bool dml2_validate(const struct dc *in_dreturn out; } +DC_FP_START (); +/* Use dml_validate_only for fast_validate path */ if (fast_validate) out =dml2_validate_only (context);else out =dml2_validate_and_build_resource (in_dc, context); + +DC_FP_END (); +return out; }
Greg Kroah-Hartman
maintainerPATCH 168/223 drm/amd/display: Protect FPU in dml21_copy()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit 4408b59eeacfea777aae397177f49748cadde5ce upstream.
Commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context start") removes the FP context protection of dml2_create(), and it said "All the DC_FP_START/END should be used before call anything from DML2".
However, dml21_copy() are not protected from their callers, causing such errors:
do_fpu invoked from kernel context![#1]:
CPU: 0 UID: 0 PID: 240 Comm: kworker/0:5 Not tainted 6.14.0-rc6+ #1
Workqueue: events work_for_cpu_fn
pc ffff80000318bd2c ra ffff80000315750c tp 9000000105910000 sp 9000000105913810
a0 0000000000000000 a1 0000000000000002 a2 900000013140d728 a3 900000013140d720
a4 0000000000000000 a5 9000000131592d98 a6 0000000000017ae8 a7 00000000001312d0
t0 9000000130751ff0 t1 ffff800003790000 t2 ffff800003790000 t3 9000000131592e28
t4 000000000004c6a8 t5 00000000001b7740 t6 0000000000023e38 t7 0000000000249f00
t8 0000000000000002 u0 0000000000000000 s9 900000012b010000 s0 9000000131400000
s1 9000000130751fd8 s2 ffff800003408000 s3 9000000130752c78 s4 9000000131592da8
s5 9000000131592120 s6 9000000130751ff0 s7 9000000131592e28 s8 9000000131400008
ra: ffff80000315750c dml2_top_soc15_initialize_instance+0x20c/0x300 [amdgpu]
ERA: ffff80000318bd2c mcg_dcn4_build_min_clock_table+0x14c/0x600 [amdgpu]
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
PRMD: 00000004 (PPLV0 +PIE -PWE)
EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 000f0000 [FPD] (IS= ECode=15 EsubCode=0)
PRID: 0014d010 (Loongson-64bit, Loongson-3C6000/S)
Process kworker/0:5 (pid: 240, threadinfo=00000000f1700428, task=0000000020d2e962)
Stack : 0000000000000000 0000000000000000 0000000000000000 9000000130751fd8
9000000131400000 ffff8000031574e0 9000000130751ff0 0000000000000000
9000000131592e28 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 0000000000000000
0000000000000000 0000000000000000 0000000000000000 f9175936df5d7fd2
900000012b00ff08 900000012b000000 ffff800003409000 ffff8000034a1780
90000001019634c0 900000012b000010 90000001307beeb8 90000001306b0000
0000000000000001 ffff8000031942b4 9000000130780000 90000001306c0000
9000000130780000 ffff8000031c276c 900000012b044bd0 ffff800003408000
...
Call Trace:
[<ffff80000318bd2c>] mcg_dcn4_build_min_clock_table+0x14c/0x600 [amdgpu]
[<ffff800003157508>] dml2_top_soc15_initialize_instance+0x208/0x300 [amdgpu]
[<ffff8000031942b0>] dml21_create_copy+0x30/0x60 [amdgpu]
[<ffff8000031c2768>] dc_state_create_copy+0x68/0xe0 [amdgpu]
[<ffff800002e98ea0>] amdgpu_dm_init+0x8c0/0x2060 [amdgpu]
[<ffff800002e9a658>] dm_hw_init+0x18/0x60 [amdgpu]
[<ffff800002b0a738>] amdgpu_device_init+0x1938/0x27e0 [amdgpu]
[<ffff800002b0ce80>] amdgpu_driver_load_kms+0x20/0xa0 [amdgpu]
[<ffff800002b008f0>] amdgpu_pci_probe+0x1b0/0x580 [amdgpu]
[<9000000003c7eae4>] local_pci_probe+0x44/0xc0
[<90000000032f2b18>] work_for_cpu_fn+0x18/0x40
[<90000000032f5da0>] process_one_work+0x160/0x300
[<90000000032f6718>] worker_thread+0x318/0x440
[<9000000003301b8c>] kthread+0x12c/0x220
[<90000000032b1484>] ret_from_kernel_thread+0x8/0xa4Unfortunately, protecting dml21_copy() out of DML2 causes "sleeping function called from invalid context", so protect them with DC_FP_START() and DC_FP_END() inside.
--- drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_wrapper.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_wrapper.c +4 -0
@@ -425,8 +425,12 @@ void dml21_copy(struct dml2_context *dst dst_dml_ctx->v21.mode_programming.programming = dst_dml2_programming; +DC_FP_START (); +/* need to initialize copied instance for internal references to be correct */ dml2_initialize_instance (&dst_dml_ctx->v21.dml_init); + +DC_FP_END (); } bool dml21_create_copy(struct dml2_context **dst_dml_ctx,
Greg Kroah-Hartman
maintainerPATCH 169/223 drm/amdgpu/mes11: optimize MES pipe FW version fetching
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <[email protected]>
commit b71a2bb0ce07f40f92f59ed7f283068e41b10075 upstream.
Don't fetch it again if we already have it. It seems the registers don't reliably have the value at resume in some cases.
--- drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c +4 -0
@@ -859,6 +859,10 @@ static void mes_v11_0_get_fw_version(str {int pipe; +/* return early if we have already fetched these */ +if (adev->mes.sched_version && adev->mes.kiq_version) +return ; +/* get MES scheduler/KIQ versions */ mutex_lock (&adev->srbm_mutex);
Greg Kroah-Hartman
maintainerPATCH 170/223 drm/amdgpu/dma_buf: fix page_link check
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <[email protected]>
commit c0dd8a9253fadfb8e5357217d085f1989da4ef0a upstream.
The page_link lower bits of the first sg could contain something like SG_END, if we are mapping a single VRAM page or contiguous blob which fits into one sg entry. Rather pull out the struct page, and use that in our check to know if we mapped struct pages vs VRAM.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c +1 -1
@@ -181,7 +181,7 @@ static void amdgpu_dma_buf_unmap(struct struct sg_table *sgt, enum dma_data_direction dir) { -if (sgt->sgl->page_link) { + if (sg_page(sgt->sgl)) {dma_unmap_sgtable (attach->dev, sgt, dir,0 );sg_free_table (sgt);kfree (sgt);
Greg Kroah-Hartman
maintainerPATCH 171/223 drm/nouveau: prime: fix ttm_bo_delayed_delete oops
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Bainbridge <[email protected]>
commit 8ec0fbb28d049273bfd4f1e7a5ae4c74884beed3 upstream.
Fix an oops in ttm_bo_delayed_delete which results from dererencing a dangling pointer:
Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP CPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216 Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024 Workqueue: ttm ttm_bo_delayed_delete [ttm] RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290 Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b RSP: 0018:ffffbf9383473d60 EFLAGS: 00010202 RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b R13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc FS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: <TASK> ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 </TASK>
The cause of this is:
- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the reference to the shared dma_buf. The reference count is 0, so the dma_buf is destroyed, which in turn decrements the corresponding amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed - calling drm_gem_object_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo.
- nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpu_bo.
- nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls ttm_bo_release, which schedules ttm_bo_delayed_delete.
- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault.
Fix this by moving the drm_prime_gem_destroy call from nouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will be run after ttm_bo_delayed_delete.
--- drivers/gpu/drm/nouveau/nouveau_bo.c | 3 +++ drivers/gpu/drm/nouveau/nouveau_gem.c | 3 --- 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/gpu/drm/nouveau/nouveau_bo.c +3 -0
@@ -144,6 +144,9 @@ nouveau_bo_del_ttm(struct ttm_buffer_objnouveau_bo_del_io_reserve_lru (bo);nv10_bo_put_tile_region (dev, nvbo->tile,NULL ); +if (bo->base.import_attach) +drm_prime_gem_destroy (&bo->base, bo->sg); +/* * If nouveau_bo_new() allocated this buffer, the GEM object was never * initialized, so don't attempt to release it.
drivers/gpu/drm/nouveau/nouveau_gem.c +0 -3
@@ -87,9 +87,6 @@ nouveau_gem_object_del(struct drm_gem_obreturn ; } -if (gem->import_attach) -drm_prime_gem_destroy (gem, nvbo->bo.sg); -ttm_bo_put (&nvbo->bo);pm_runtime_mark_last_busy (dev);
Greg Kroah-Hartman
maintainerPATCH 172/223 drm/imagination: fix firmware memory leaks
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brendan King <[email protected]>
commit a5b230e7f3a55bd8bd8d012eec75a4b7baa671d5 upstream.
Free the memory used to hold the results of firmware image processing when the module is unloaded.
Fix the related issue of the same memory being leaked if processing of the firmware image fails during module load.
Ensure all firmware GEM objects are destroyed if firmware image processing fails.
Fixes memory leaks on powervr module unload detected by Kmemleak:
unreferenced object 0xffff000042e20000 (size 94208):
comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes):
02 ae 7f ed bf 45 84 00 3c 5b 1f ed 9f 45 45 05 .....E..<[...EE.
d5 4f 5d 14 6c 00 3d 23 30 d0 3a 4a 66 0e 48 c8 .O].l.=#0.:Jf.H.
backtrace (crc dd329dec):
kmemleak_alloc+0x30/0x40
___kmalloc_large_node+0x140/0x188
__kmalloc_large_node_noprof+0x2c/0x13c
__kmalloc_noprof+0x48/0x4c0
pvr_fw_init+0xaa4/0x1f50 [powervr]unreferenced object 0xffff000042d20000 (size 20480):
comm "modprobe", pid 470, jiffies 4295277154 hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 09 00 00 00 0b 00 00 00 ................
00 00 00 00 00 00 00 00 07 00 00 00 08 00 00 00 ................
backtrace (crc 395b02e3):
kmemleak_alloc+0x30/0x40
___kmalloc_large_node+0x140/0x188
__kmalloc_large_node_noprof+0x2c/0x13c
__kmalloc_noprof+0x48/0x4c0
pvr_fw_init+0xb0c/0x1f50 [powervr]--- drivers/gpu/drm/imagination/pvr_fw.c | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-)
drivers/gpu/drm/imagination/pvr_fw.c +20 -7
@@ -732,7 +732,7 @@ pvr_fw_process(struct pvr_device *pvr_de fw_mem->core_data, fw_mem->core_code_alloc_size);if (err) - goto err_free_fw_core_data_obj; + goto err_free_kdata;memcpy (fw_code_ptr, fw_mem->code, fw_mem->code_alloc_size);memcpy (fw_data_ptr, fw_mem->data, fw_mem->data_alloc_size);
@@ -742,10 +742,14 @@ pvr_fw_process(struct pvr_device *pvr_dememcpy (fw_core_data_ptr, fw_mem->core_data, fw_mem->core_data_alloc_size);/* We're finished with the firmware section memory on the CPU, unmap. */ -if (fw_core_data_ptr) +if (fw_core_data_ptr) {pvr_fw_object_vunmap (fw_mem->core_data_obj); -if (fw_core_code_ptr) + fw_core_data_ptr =NULL ; + } +if (fw_core_code_ptr) {pvr_fw_object_vunmap (fw_mem->core_code_obj); + fw_core_code_ptr =NULL ; + }pvr_fw_object_vunmap (fw_mem->data_obj); fw_data_ptr =NULL ;pvr_fw_object_vunmap (fw_mem->code_obj);
@@ -753,7 +757,7 @@ pvr_fw_process(struct pvr_device *pvr_de err =pvr_fw_create_fwif_connection_ctl (pvr_dev);if (err) - goto err_free_fw_core_data_obj; + goto err_free_kdata;return 0 ;
@@ -763,13 +767,16 @@ err_free_kdata:kfree (fw_mem->data);kfree (fw_mem->code); -err_free_fw_core_data_obj:if (fw_core_data_ptr) -pvr_fw_object_unmap_and_destroy (fw_mem->core_data_obj); +pvr_fw_object_vunmap (fw_mem->core_data_obj); +if (fw_mem->core_data_obj) +pvr_fw_object_destroy (fw_mem->core_data_obj); err_free_fw_core_code_obj:if (fw_core_code_ptr) -pvr_fw_object_unmap_and_destroy (fw_mem->core_code_obj); +pvr_fw_object_vunmap (fw_mem->core_code_obj); +if (fw_mem->core_code_obj) +pvr_fw_object_destroy (fw_mem->core_code_obj); err_free_fw_data_obj:if (fw_data_ptr)
@@ -836,6 +843,12 @@ pvr_fw_cleanup(struct pvr_device *pvr_destruct pvr_fw_mem *fw_mem = &pvr_dev->fw_dev.mem;pvr_fw_fini_fwif_connection_ctl (pvr_dev); + +kfree (fw_mem->core_data); +kfree (fw_mem->core_code); +kfree (fw_mem->data); +kfree (fw_mem->code); +if (fw_mem->core_code_obj)pvr_fw_object_destroy (fw_mem->core_code_obj);if (fw_mem->core_data_obj)
Greg Kroah-Hartman
maintainerPATCH 173/223 drm/imagination: take paired job reference
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Brendan King <[email protected]>
commit 4ba2abe154ef68f9612eee9d6fbfe53a1736b064 upstream.
For paired jobs, have the fragment job take a reference on the geometry job, so that the geometry job cannot be freed until the fragment job has finished with it.
The geometry job structure is accessed when the fragment job is being prepared by the GPU scheduler. Taking the reference prevents the geometry job being freed until the fragment job no longer requires it.
Fixes a use after free bug detected by KASAN:
[ 124.256386] BUG: KASAN: slab-use-after-free in pvr_queue_prepare_job+0x108/0x868 [powervr] [ 124.264893] Read of size 1 at addr ffff0000084cb960 by task kworker/u16:4/63
--- drivers/gpu/drm/imagination/pvr_job.c | 7 +++++++ drivers/gpu/drm/imagination/pvr_queue.c | 4 ++++ 2 files changed, 11 insertions(+)
drivers/gpu/drm/imagination/pvr_job.c +7 -0
@@ -684,6 +684,13 @@ pvr_jobs_link_geom_frag(struct pvr_job_d geom_job->paired_job = frag_job; frag_job->paired_job = geom_job; +/* The geometry job pvr_job structure is used when the fragment +* job is being prepared by the GPU scheduler. Have the fragment +* job hold a reference on the geometry job to prevent it being +* freed until the fragment job has finished with it. +*/ +pvr_job_get (geom_job); +/* Skip the fragment job we just paired to the geometry job. */ i++; }
drivers/gpu/drm/imagination/pvr_queue.c +4 -0
@@ -866,6 +866,10 @@ static void pvr_queue_free_job(struct dr struct pvr_job *job = container_of(sched_job, struct pvr_job, base);drm_sched_job_cleanup (sched_job); + +if (job->type ==DRM_PVR_JOB_TYPE_FRAGMENT && job->paired_job) +pvr_job_put (job->paired_job); + job->paired_job =NULL ;pvr_job_put (job); }
Greg Kroah-Hartman
maintainerPATCH 174/223 drm/sti: remove duplicate object names
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rolf Eike Beer <[email protected]>
commit 7fb6afa9125fc111478615e24231943c4f76cc2e upstream.
When merging 2 drivers common object files were not deduplicated.
--- drivers/gpu/drm/sti/Makefile | 2 -- 1 file changed, 2 deletions(-)
drivers/gpu/drm/sti/Makefile +0 -2
@@ -7,8 +7,6 @@ sti-drm-y := \ sti_compositor.o \ sti_crtc.o \ sti_plane.o \ - sti_crtc.o \ - sti_plane.o \ sti_hdmi.o \ sti_hdmi_tx3g4c28phy.o \ sti_dvo.o \
Greg Kroah-Hartman
maintainerPATCH 175/223 drm/xe: Fix an out-of-bounds shift when invalidating TLB
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Hellström <[email protected]>
commit 7bcfeddb36b77f9fe3b010bb0b282b7618420bba upstream.
When the size of the range invalidated is larger than rounddown_pow_of_two(ULONG_MAX),
The function macro roundup_pow_of_two(length) will hit an out-of-bounds shift [1].
Use a full TLB invalidation for such cases.
v2:
- Use a define for the range size limit over which we use a full TLB invalidation. (Lucas)
- Use a better calculation of the limit.
[1]:
[ 39.202421] ------------[ cut here ]------------ [ 39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 [ 39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int' [ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G U 6.14.0+ #10 [ 39.202690] Tainted: [U]=USER [ 39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 39.202691] Call Trace: [ 39.202692] <TASK> [ 39.202695] dump_stack_lvl+0x6e/0xa0 [ 39.202699] ubsan_epilogue+0x5/0x30 [ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe] [ 39.202800] ? find_held_lock+0x2b/0x80 [ 39.202803] ? mark_held_locks+0x40/0x70 [ 39.202806] xe_svm_invalidate+0x459/0x700 [xe] [ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm] [ 39.202900] __mmu_notifier_release+0x1f5/0x270 [ 39.202905] exit_mmap+0x40e/0x450 [ 39.202912] __mmput+0x45/0x110 [ 39.202914] exit_mm+0xc5/0x130 [ 39.202916] do_exit+0x21c/0x500 [ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190 [ 39.202920] do_group_exit+0x36/0xa0 [ 39.202922] get_signal+0x8f8/0x900 [ 39.202926] arch_do_signal_or_restart+0x35/0x100 [ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290 [ 39.202932] do_syscall_64+0xa1/0x180 [ 39.202934] ? do_user_addr_fault+0x59f/0x8a0 [ 39.202937] ? lock_release+0xd2/0x2a0 [ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0 [ 39.202942] ? trace_hardirqs_off+0x4b/0xc0 [ 39.202944] ? clear_bhb_loop+0x25/0x80 [ 39.202946] ? clear_bhb_loop+0x25/0x80 [ 39.202947] ? clear_bhb_loop+0x25/0x80 [ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 39.202952] RIP: 0033:0x7fa945e543e1 [ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7. [ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293 [ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3 [ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff [ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0 [ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000 [ 39.202970] </TASK> [ 39.202970] ---[ end trace ]---
--- drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)
drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c +10 -2
@@ -310,6 +310,13 @@ int xe_gt_tlb_invalidation_ggtt(struct xreturn 0 ; } +/* +* Ensure that roundup_pow_of_two(length) doesn't overflow. +* Note that roundup_pow_of_two() operates on unsigned long, +* not on u64. +*/ +#define MAX_RANGE_TLB_INVALIDATION_LENGTH (rounddown_pow_of_two(ULONG_MAX)) +/** * xe_gt_tlb_invalidation_range - Issue a TLB invalidation on this GT for an * address range
@@ -334,6 +341,7 @@ int xe_gt_tlb_invalidation_range(structstruct xe_device *xe =gt_to_xe (gt);#define MAX_TLB_INVALIDATION_LEN 7u32 action[MAX_TLB_INVALIDATION_LEN ]; +u64 length = end - start;int len =0 ;xe_gt_assert (gt, fence);
@@ -346,11 +354,11 @@ int xe_gt_tlb_invalidation_range(struct action[len++] =XE_GUC_ACTION_TLB_INVALIDATION ; action[len++] =0 ;/* seqno, replaced in send_tlb_invalidation */ -if (!xe->info.has_range_tlb_invalidation) { +if (!xe->info.has_range_tlb_invalidation || + length >MAX_RANGE_TLB_INVALIDATION_LENGTH ) { action[len++] =MAKE_INVAL_OP (XE_GUC_TLB_INVAL_FULL ); }else {u64 orig_start = start; -u64 length = end - start;u64 align;if (length <SZ_4K )
Greg Kroah-Hartman
maintainerPATCH 176/223 drm/i915/gvt: fix unterminated-string-initialization warning
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jani Nikula <[email protected]>
commit 2e43ae7dd71cd9bb0d1bce1d3306bf77523feb81 upstream.
Initializing const char opregion_signature[16] = OPREGION_SIGNATURE (which is "IntelGraphicsMem") drops the NUL termination of the string. This is intentional, but the compiler doesn't know this.
Switch to initializing header->signature directly from the string litaral, with sizeof destination rather than source. We don't treat the signature as a string other than for initialization; it's really just a blob of binary data.
Add a static assert for good measure to cross-check the sizes.
--- drivers/gpu/drm/i915/gvt/opregion.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/gpu/drm/i915/gvt/opregion.c +4 -3
@@ -222,7 +222,6 @@ int intel_vgpu_init_opregion(struct inteu8 *buf;struct opregion_header *header;struct vbt v; -const char opregion_signature[16 ] =OPREGION_SIGNATURE ;gvt_dbg_core ("init vgpu%d opregion\n" , vgpu->id); vgpu_opregion(vgpu)->va = (void *)__get_free_pages(GFP_KERNEL |
@@ -236,8 +235,10 @@ int intel_vgpu_init_opregion(struct inte/* emulated opregion with VBT mailbox only */ buf = (u8 *)vgpu_opregion (vgpu)->va; header = (struct opregion_header *)buf; -memcpy (header->signature, opregion_signature, -sizeof (opregion_signature)); + +static_assert (sizeof (header->signature) ==sizeof (OPREGION_SIGNATURE ) -1 ); +memcpy (header->signature,OPREGION_SIGNATURE ,sizeof (header->signature)); + header->size =0x8 ; header->opregion_ver =0x02000000 ; header->mboxes =MBOX_VBT ;
Greg Kroah-Hartman
maintainerPATCH 177/223 drm/amdgpu: immediately use GTT for new allocations
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian König <[email protected]>
commit a755906fb2b8370c43e91ba437ae1b3e228e8b02 upstream.
Only use GTT as a fallback if we already have a backing store. This prevents evictions when an application constantly allocates and frees new memory.
Partially fixes
https://gitlab.freedesktop.org/drm/amd/-/issues/3844#note_2833985.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +2 -2
@@ -161,8 +161,8 @@ void amdgpu_bo_placement_from_domain(str* When GTT is just an alternative to VRAM make sure that we * only use it as fallback and still try to fill up VRAM first. */ -if (domain & abo->preferred_domains &AMDGPU_GEM_DOMAIN_VRAM && - !(adev->flags &AMD_IS_APU )) +if (abo->tbo.resource && !(adev->flags &AMD_IS_APU ) && + domain & abo->preferred_domains &AMDGPU_GEM_DOMAIN_VRAM ) places[c].flags |=TTM_PL_FLAG_FALLBACK ; c++; }
Greg Kroah-Hartman
maintainerPATCH 178/223 drm/amd/display: Do not enable Replay and PSR while VRR is on in amdgpu_dm_commit_planes()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tom Chung <[email protected]>
commit 69a46ce1f15b4391c128d581f6936750f9bfa052 upstream.
[Why]
Replay and PSR will cause some video corruption while VRR is enabled.
[How]
Do not enable the Replay and PSR while VRR is active in amdgpu_dm_enable_self_refresh().
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c +4 -2
@@ -113,6 +113,7 @@ bool amdgpu_dm_crtc_vrr_active(const struct dm_crtc_state *dm_state)* * Panel Replay and PSR SU * - Enable when: +* - VRR is disabled * - vblank counter is disabled * - entry is allowed: usermode demonstrates an adequate number of fast * commits)
@@ -131,19 +132,20 @@ static void amdgpu_dm_crtc_set_panel_sr_feature(bool is_sr_active = (link->replay_settings.replay_allow_active || link->psr_settings.psr_allow_active);bool is_crc_window_active = false; +bool vrr_active =amdgpu_dm_crtc_vrr_active_irq (vblank_work->acrtc);#ifdef CONFIG_DRM_AMD_SECURE_DISPLAY is_crc_window_active =amdgpu_dm_crc_window_is_activated (&vblank_work->acrtc->base);#endif -if (link->replay_settings.replay_feature_enabled && +if (link->replay_settings.replay_feature_enabled && !vrr_active && allow_sr_entry && !is_sr_active && !is_crc_window_active) {amdgpu_dm_replay_enable (vblank_work->stream, true); }else if (vblank_enabled) {if (link->psr_settings.psr_version <DC_PSR_VERSION_SU_1 && is_sr_active)amdgpu_dm_psr_disable (vblank_work->stream, false); - }else if (link->psr_settings.psr_feature_enabled && + }else if (link->psr_settings.psr_feature_enabled && !vrr_active && allow_sr_entry && !is_sr_active && !is_crc_window_active) { struct amdgpu_dm_connector *aconn =
Signature · 1 line
2.49.0
Greg Kroah-Hartman
maintainerPATCH 179/223 drm/amd/display: Protect FPU in dml2_init()/dml21_init()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huacai Chen <[email protected]>
commit afcdf51d97cd58dd7a2e0aa8acbaea5108fa6826 upstream.
Commit 7da55c27e76749b9 ("drm/amd/display: Remove incorrect FP context start") removes the FP context protection of dml2_create(), and it said "All the DC_FP_START/END should be used before call anything from DML2".
However, dml2_init()/dml21_init() are not protected from their callers, causing such errors:
do_fpu invoked from kernel context![#1]:
CPU: 0 UID: 0 PID: 239 Comm: kworker/0:5 Not tainted 6.14.0-rc6+ #2
Workqueue: events work_for_cpu_fn
pc ffff80000319de80 ra ffff80000319de5c tp 900000010575c000 sp 900000010575f840
a0 0000000000000000 a1 900000012f210130 a2 900000012f000000 a3 ffff80000357e268
a4 ffff80000357e260 a5 900000012ea52cf0 a6 0000000400000004 a7 0000012c00001388
t0 00001900000015e0 t1 ffff80000379d000 t2 0000000010624dd3 t3 0000006400000014
t4 00000000000003e8 t5 0000005000000018 t6 0000000000000020 t7 0000000f00000064
t8 000000000000002f u0 5f5e9200f8901912 s9 900000012d380010 s0 900000012ea51fd8
s1 900000012f000000 s2 9000000109296000 s3 0000000000000001 s4 0000000000001fd8
s5 0000000000000001 s6 ffff800003415000 s7 900000012d390000 s8 ffff800003211f80
ra: ffff80000319de5c dml21_apply_soc_bb_overrides+0x3c/0x960 [amdgpu]
ERA: ffff80000319de80 dml21_apply_soc_bb_overrides+0x60/0x960 [amdgpu]
CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
PRMD: 00000004 (PPLV0 +PIE -PWE)
EUEN: 00000000 (-FPE -SXE -ASXE -BTE)
ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
ESTAT: 000f0000 [FPD] (IS= ECode=15 EsubCode=0)
PRID: 0014d010 (Loongson-64bit, Loongson-3C6000/S)
Process kworker/0:5 (pid: 239, threadinfo=00000000927eadc6, task=000000008fd31682)
Stack : 00040dc000003164 0000000000000001 900000012f210130 900000012eabeeb8
900000012f000000 ffff80000319fe48 900000012f210000 900000012f210130
900000012f000000 900000012eabeeb8 0000000000000001 ffff8000031a0064
900000010575f9f0 900000012f210130 900000012eac0000 900000012ea80000
900000012f000000 ffff8000031cefc4 900000010575f9f0 ffff8000035859c0
ffff800003414000 900000010575fa78 900000012f000000 ffff8000031b4c50
0000000000000000 9000000101c9d700 9000000109c40000 5f5e9200f8901912
900000012d3c4bd0 900000012d3c5000 ffff8000034aed18 900000012d380010
900000012d3c4bd0 ffff800003414000 900000012d380000 ffff800002ea49dc
0000000000000001 900000012d3c6000 00000000ffffe423 0000000000010000
...
Call Trace:
[<ffff80000319de80>] dml21_apply_soc_bb_overrides+0x60/0x960 [amdgpu]
[<ffff80000319fe44>] dml21_init+0xa4/0x280 [amdgpu]
[<ffff8000031a0060>] dml21_create+0x40/0x80 [amdgpu]
[<ffff8000031cefc0>] dc_state_create+0x100/0x160 [amdgpu]
[<ffff8000031b4c4c>] dc_create+0x44c/0x640 [amdgpu]
[<ffff800002ea49d8>] amdgpu_dm_init+0x3f8/0x2060 [amdgpu]
[<ffff800002ea6658>] dm_hw_init+0x18/0x60 [amdgpu]
[<ffff800002b16738>] amdgpu_device_init+0x1938/0x27e0 [amdgpu]
[<ffff800002b18e80>] amdgpu_driver_load_kms+0x20/0xa0 [amdgpu]
[<ffff800002b0c8f0>] amdgpu_pci_probe+0x1b0/0x580 [amdgpu]
[<900000000448eae4>] local_pci_probe+0x44/0xc0
[<9000000003b02b18>] work_for_cpu_fn+0x18/0x40
[<9000000003b05da0>] process_one_work+0x160/0x300
[<9000000003b06718>] worker_thread+0x318/0x440
[<9000000003b11b8c>] kthread+0x12c/0x220
[<9000000003ac1484>] ret_from_kernel_thread+0x8/0xa4Unfortunately, protecting dml2_init()/dml21_init() out of DML2 causes "sleeping function called from invalid context", so protect them with DC_FP_START() and DC_FP_END() inside.
--- drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_wrapper.c | 4 ++++ drivers/gpu/drm/amd/display/dc/dml2/dml2_wrapper.c | 4 ++++ 2 files changed, 8 insertions(+)
drivers/gpu/drm/amd/display/dc/dml2/dml21/dml21_wrapper.c +4 -0
@@ -87,6 +87,8 @@ static void dml21_init(const struct dc */* Store configuration options */ (*dml_ctx)->config = *config; +DC_FP_START (); +/*Initialize SOCBB and DCNIP params */ dml21_initialize_soc_bb_params (&(*dml_ctx)->v21.dml_init, config, in_dc);dml21_initialize_ip_params (&(*dml_ctx)->v21.dml_init, config, in_dc);
@@ -97,6 +99,8 @@ static void dml21_init(const struct dc */*Initialize DML21 instance */ dml2_initialize_instance (&(*dml_ctx)->v21.dml_init); + +DC_FP_END (); }bool dml21_create (const struct dc *in_dc,struct dml2_context **dml_ctx,const struct dml2_configuration_options *config)
drivers/gpu/drm/amd/display/dc/dml2/dml2_wrapper.c +4 -0
@@ -784,11 +784,15 @@ static void dml2_init(const struct dc *ibreak ; } +DC_FP_START (); +initialize_dml2_ip_params (*dml2, in_dc, &(*dml2)->v20.dml_core_ctx.ip);initialize_dml2_soc_bbox (*dml2, in_dc, &(*dml2)->v20.dml_core_ctx.soc);initialize_dml2_soc_states (*dml2, in_dc, &(*dml2)->v20.dml_core_ctx.soc, &(*dml2)->v20.dml_core_ctx.states); + +DC_FP_END (); }bool dml2_create (const struct dc *in_dc,const struct dml2_configuration_options *config,struct dml2_context **dml2)
Greg Kroah-Hartman
maintainerPATCH 180/223 drm/amd/display: Add HP Probook 445 and 465 to the quirk list for eDP on DP1
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mario Limonciello <[email protected]>
commit 139e99d58e373bd11f085766e681d21d34d0b097 upstream.
[Why]
HP Probook 445 and 465 has DP0 and DP1 swapped.
[How]
Add HP Probook 445 and 465 to DP0/DP1 swap quirk list.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +14 -0
@@ -1704,6 +1704,20 @@ static const struct dmi_system_id dmi_qu DMI_MATCH(DMI_PRODUCT_NAME, "HP EliteBook 665 16 inch G11 Notebook PC"), }, }, + { + .callback = edp0_on_dp1_callback, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "HP"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook 445 14 inch G11 Notebook PC"), + }, + }, + { + .callback = edp0_on_dp1_callback, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "HP"), + DMI_MATCH(DMI_PRODUCT_NAME, "HP ProBook 465 16 inch G11 Notebook PC"), + }, + }, {}/* TODO: refactor this from a fixed table to a dynamic option */ };
Greg Kroah-Hartman
maintainerPATCH 181/223 drm/xe/dma_buf: stop relying on placement in unmap
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <[email protected]>
commit 25583ad42d091819157832e894179200ba8b54ee upstream.
The is_vram() is checking the current placement, however if we consider exported VRAM with dynamic dma-buf, it looks possible for the xe driver to async evict the memory, notifying the importer, however importer does not have to call unmap_attachment() immediately, but rather just as "soon as possible", like when the dma-resv idles. Following from this we would then pipeline the move, attaching the fence to the manager, and then update the current placement. But when the unmap_attachment() runs at some later point we might see that is_vram() is now false, and take the complete wrong path when dma-unmapping the sg, leading to explosions.
To fix this check if the sgl was mapping a struct page.
v2:
- The attachment can be mapped multiple times it seems, so we can't really rely on encoding something in the attachment->priv. Instead see if the page_link has an encoded struct page. For vram we expect this to be NULL.
--- drivers/gpu/drm/xe/xe_dma_buf.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
drivers/gpu/drm/xe/xe_dma_buf.c +1 -4
@@ -145,10 +145,7 @@ static void xe_dma_buf_unmap(struct dma_ struct sg_table *sgt, enum dma_data_direction dir) { -struct dma_buf *dma_buf = attach->dmabuf; -struct xe_bo *bo =gem_to_xe_bo (dma_buf->priv); - -if (!xe_bo_is_vram (bo)) { + if (sg_page(sgt->sgl)) {dma_unmap_sgtable (attach->dev, sgt, dir,0 );sg_free_table (sgt);kfree (sgt);
Greg Kroah-Hartman
maintainerPATCH 182/223 drm/xe/userptr: fix notifier vs folio deadlock
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Matthew Auld <[email protected]>
commit 2577b202458cddff85cc154b1fe7f313e0d1f418 upstream.
User is reporting what smells like notifier vs folio deadlock, where migrate_pages_batch() on core kernel side is holding folio lock(s) and then interacting with the mappings of it, however those mappings are tied to some userptr, which means calling into the notifier callback and grabbing the notifier lock. With perfect timing it looks possible that the pages we pulled from the hmm fault can get sniped by migrate_pages_batch() at the same time that we are holding the notifier lock to mark the pages as accessed/dirty, but at this point we also want to grab the folio locks(s) to mark them as dirty, but if they are contended from notifier/migrate_pages_batch side then we deadlock since folio lock won't be dropped until we drop the notifier lock.
Fortunately the mark_page_accessed/dirty is not really needed in the first place it seems and should have already been done by hmm fault, so just remove it.
--- drivers/gpu/drm/xe/xe_hmm.c | 24 ------------------------ 1 file changed, 24 deletions(-)
drivers/gpu/drm/xe/xe_hmm.c +0 -24
@@ -19,29 +19,6 @@ static u64 xe_npages_in_range(unsigned lreturn (end - start) >>PAGE_SHIFT ; } -/** -* xe_mark_range_accessed() - mark a range is accessed, so core mm -* have such information for memory eviction or write back to -* hard disk -* @range: the range to mark -* @write: if write to this range, we mark pages in this range -* as dirty -*/ -static void xe_mark_range_accessed (struct hmm_range *range,bool write) -{ -struct page *page; -u64 i, npages; - - npages =xe_npages_in_range (range->start, range->end); -for (i =0 ; i < npages; i++) { - page =hmm_pfn_to_page (range->hmm_pfns[i]); -if (write) -set_page_dirty_lock (page); - -mark_page_accessed (page); - } -} -static int xe_alloc_sg (struct xe_device *xe,struct sg_table *st,struct hmm_range *range,struct rw_semaphore *notifier_sem) {
@@ -331,7 +308,6 @@ int xe_hmm_userptr_populate_range(structif (ret) goto out_unlock; -xe_mark_range_accessed (&hmm_range, write); userptr->sg = &userptr->sgt;xe_hmm_userptr_set_mapped (uvma); userptr->notifier_seq = hmm_range.notifier_seq;
Greg Kroah-Hartman
maintainerPATCH 183/223 drm/xe: Set LRC addresses before guc load
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lucas De Marchi <[email protected]>
commit 6405f5b70b1c240ffddef01c7a140498f47d4fe7 upstream.
The metadata saved in the ADS is read by GuC when it's initialized. Saving the addresses to the LRCs when they are populated is too late as GuC will keep using the old ones.
This was causing GuC to use the RCS LRC for any engine class. It's not a big problem on a Linux-only scenario since the they are used by GuC only on media engines when the watchdog is triggered. However, in a virtualization scenario with Windows as the VF, it causes the wrong LRCs to be loaded as the watchdog is used for all engines.
Fix it by letting guc_golden_lrc_init() initialize the metadata, like other *_init() functions, and later guc_golden_lrc_populate() to copy the LRCs to the right places. The former is called before the second GuC load, while the latter is called after LRCs have been recorded.
--- drivers/gpu/drm/xe/xe_guc_ads.c | 75 ++++++++++++++++++++++++---------------- 1 file changed, 45 insertions(+), 30 deletions(-)
drivers/gpu/drm/xe/xe_guc_ads.c +45 -30
@@ -483,24 +483,52 @@ static void fill_engine_enable_masks(str engine_enable_mask(gt, XE_ENGINE_CLASS_OTHER)); } -static void guc_prep_golden_lrc_null (struct xe_guc_ads *ads) +/* +* Write the offsets corresponding to the golden LRCs. The actual data is +* populated later by guc_golden_lrc_populate() +*/ +static void guc_golden_lrc_init (struct xe_guc_ads *ads) {struct xe_device *xe =ads_to_xe (ads); +struct xe_gt *gt =ads_to_gt (ads);struct iosys_map info_map =IOSYS_MAP_INIT_OFFSET (ads_to_map (ads), offsetof(struct __guc_ads_blob , system_info)); -u8 guc_class; +size_t alloc_size, real_size; +u32 addr_ggtt, offset; +int class; + + offset =guc_ads_golden_lrc_offset (ads); + addr_ggtt =xe_bo_ggtt_addr (ads->bo) + offset; + +for (class =0 ; class <XE_ENGINE_CLASS_MAX ; ++class) { +u8 guc_class; + + guc_class =xe_engine_class_to_guc_class (class); -for (guc_class =0 ; guc_class <=GUC_MAX_ENGINE_CLASSES ; ++guc_class) {if (!info_map_read (xe, &info_map, engine_enabled_masks[guc_class]))continue ; + real_size =xe_gt_lrc_size (gt, class); + alloc_size =PAGE_ALIGN (real_size); + +/* +* This interface is slightly confusing. We need to pass the +* base address of the full golden context and the size of just +* the engine state, which is the section of the context image +* that starts after the execlists LRC registers. This is +* required to allow the GuC to restore just the engine state +* when a watchdog reset occurs. +* We calculate the engine state size by removing the size of +* what comes before it in the context image (which is identical +* on all engines). +*/ ads_blob_write (ads, ads.eng_state_size[guc_class], -guc_ads_golden_lrc_size (ads) - -xe_lrc_skip_size (xe)); + real_size -xe_lrc_skip_size (xe));ads_blob_write (ads, ads.golden_context_lrca[guc_class], -xe_bo_ggtt_addr (ads->bo) + -guc_ads_golden_lrc_offset (ads)); + addr_ggtt); + + addr_ggtt += alloc_size; } }
@@ -710,7 +738,7 @@ void xe_guc_ads_populate_minimal(structxe_map_memset (ads_to_xe (ads),ads_to_map (ads),0 ,0 , ads->bo->size);guc_policies_init (ads); -guc_prep_golden_lrc_null (ads); +guc_golden_lrc_init (ads);guc_mapping_table_init_invalid (gt, &info_map);guc_doorbell_init (ads);
@@ -736,7 +764,7 @@ void xe_guc_ads_populate(struct xe_guc_aguc_policies_init (ads);fill_engine_enable_masks (gt, &info_map);guc_mmio_reg_state_init (ads); -guc_prep_golden_lrc_null (ads); +guc_golden_lrc_init (ads);guc_mapping_table_init (gt, &info_map);guc_capture_list_init (ads);guc_doorbell_init (ads);
@@ -756,18 +784,22 @@ void xe_guc_ads_populate(struct xe_guc_a guc_ads_private_data_offset(ads)); } -static void guc_populate_golden_lrc (struct xe_guc_ads *ads) +/* +* After the golden LRC's are recorded for each engine class by the first +* submission, copy them to the ADS, as initialized earlier by +* guc_golden_lrc_init(). +*/ +static void guc_golden_lrc_populate (struct xe_guc_ads *ads) {struct xe_device *xe =ads_to_xe (ads);struct xe_gt *gt =ads_to_gt (ads);struct iosys_map info_map =IOSYS_MAP_INIT_OFFSET (ads_to_map (ads), offsetof(struct __guc_ads_blob , system_info));size_t total_size =0 , alloc_size, real_size; -u32 addr_ggtt, offset; +u32 offset;int class; offset =guc_ads_golden_lrc_offset (ads); - addr_ggtt =xe_bo_ggtt_addr (ads->bo) + offset;for (class =0 ; class <XE_ENGINE_CLASS_MAX ; ++class) {u8 guc_class;
@@ -784,26 +816,9 @@ static void guc_populate_golden_lrc(stru alloc_size =PAGE_ALIGN (real_size); total_size += alloc_size; -/* -* This interface is slightly confusing. We need to pass the -* base address of the full golden context and the size of just -* the engine state, which is the section of the context image -* that starts after the execlists LRC registers. This is -* required to allow the GuC to restore just the engine state -* when a watchdog reset occurs. -* We calculate the engine state size by removing the size of -* what comes before it in the context image (which is identical -* on all engines). -*/ -ads_blob_write (ads, ads.eng_state_size[guc_class], - real_size -xe_lrc_skip_size (xe)); -ads_blob_write (ads, ads.golden_context_lrca[guc_class], - addr_ggtt); -xe_map_memcpy_to (xe,ads_to_map (ads), offset, gt->default_lrc[class], real_size); - addr_ggtt += alloc_size; offset += alloc_size; }
@@ -812,7 +827,7 @@ static void guc_populate_golden_lrc(struvoid xe_guc_ads_populate_post_load (struct xe_guc_ads *ads) { -guc_populate_golden_lrc (ads); +guc_golden_lrc_populate (ads); }static int guc_ads_action_update_policies (struct xe_guc_ads *ads,u32 policy_offset)
Greg Kroah-Hartman
maintainerPATCH 184/223 drm/amdgpu: fix warning of drm_mm_clean
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: ZhenGuo Yin <[email protected]>
commit e7afa85a0d0eba5bf2c0a446ff622ebdbc9812d6 upstream.
Kernel doorbell BOs needs to be freed before ttm_fini.
--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +1 -1
@@ -3322,6 +3322,7 @@ static int amdgpu_device_ip_fini(structamdgpu_device_mem_scratch_fini (adev);amdgpu_ib_pool_fini (adev);amdgpu_seq64_fini (adev); +amdgpu_doorbell_fini (adev); } r = adev->ip_blocks[i].version->funcs->sw_fini ((void *)adev);
@@ -4670,7 +4671,6 @@ void amdgpu_device_fini_sw(struct amdgpuiounmap (adev->rmmio); adev->rmmio =NULL ; -amdgpu_doorbell_fini (adev);drm_dev_exit (idx); }
Greg Kroah-Hartman
maintainerPATCH 185/223 drm/mgag200: Fix value in <VBLKSTR> register
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit 76c332d119f9048c6e16b52359f401510f18b2ff upstream.
Fix an off-by-one error when setting the vblanking start in <VBLKSTR>. Commit d6460bd52c27 ("drm/mgag200: Add dedicated variables for blanking fields") switched the value from crtc_vdisplay to crtc_vblank_start, which DRM helpers copy from the former. The commit missed to subtract one though.
--- drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/mgag200/mgag200_mode.c +1 -1
@@ -223,7 +223,7 @@ void mgag200_set_mode_regs(struct mga_de vsyncstr = mode->crtc_vsync_start -1 ; vsyncend = mode->crtc_vsync_end -1 ; vtotal = mode->crtc_vtotal -2 ; - vblkstr = mode->crtc_vblank_start; + vblkstr = mode->crtc_vblank_start -1 ; vblkend = vtotal +1 ; linecomp = vdispend;
Greg Kroah-Hartman
maintainerPATCH 186/223 arm64/sysreg: Update register fields for ID_AA64MMFR0_EL1
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
commit cc15f548cc77574bcd68425ae01a796659bd3705 upstream.
This updates ID_AA64MMFR0_EL1 register fields as per the definitions based on DDI0601 2024-12.
--- arch/arm64/tools/sysreg | 2 ++ 1 file changed, 2 insertions(+)
arch/arm64/tools/sysreg +2 -0
@@ -1556,6 +1556,7 @@ EndEnum UnsignedEnum 59:56 FGT 0b0000 NI 0b0001 IMP + 0b0010 FGT2 EndEnum Res0 55:48 UnsignedEnum 47:44 EXS
@@ -1617,6 +1618,7 @@ Enum 3:0 PARANGE 0b0100 44 0b0101 48 0b0110 52 + 0b0111 56 EndEnum EndSysreg
Greg Kroah-Hartman
maintainerPATCH 187/223 arm64/sysreg: Add register fields for HDFGRTR2_EL2
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
commit 44844551670cff70a8aa5c1cde27ad1e0367e009 upstream.
This adds register fields for HDFGRTR2_EL2 as per the definitions based on DDI0601 2024-12.
--- arch/arm64/tools/sysreg | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+)
arch/arm64/tools/sysreg +29 -0
@@ -2465,6 +2465,35 @@ Field 1 ICIALLU Field 0 ICIALLUIS EndSysreg +Sysreg HDFGRTR2_EL2 3 4 3 1 0 +Res0 63:25 +Field 24 nPMBMAR_EL1 +Field 23 nMDSTEPOP_EL1 +Field 22 nTRBMPAM_EL1 +Res0 21 +Field 20 nTRCITECR_EL1 +Field 19 nPMSDSFR_EL1 +Field 18 nSPMDEVAFF_EL1 +Field 17 nSPMID +Field 16 nSPMSCR_EL1 +Field 15 nSPMACCESSR_EL1 +Field 14 nSPMCR_EL0 +Field 13 nSPMOVS +Field 12 nSPMINTEN +Field 11 nSPMCNTEN +Field 10 nSPMSELR_EL0 +Field 9 nSPMEVTYPERn_EL0 +Field 8 nSPMEVCNTRn_EL0 +Field 7 nPMSSCR_EL1 +Field 6 nPMSSDATA +Field 5 nMDSELR_EL1 +Field 4 nPMUACR_EL1 +Field 3 nPMICFILTR_EL0 +Field 2 nPMICNTR_EL0 +Field 1 nPMIAR_EL1 +Field 0 nPMECR_EL1 +EndSysreg + Sysreg HDFGRTR_EL2 3 4 3 1 4 Field 63 PMBIDR_EL1 Field 62 nPMSNEVFR_EL1
Greg Kroah-Hartman
maintainerPATCH 188/223 arm64/sysreg: Add register fields for HDFGWTR2_EL2
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
commit 2f1f62a1257b9d5eb98a8e161ea7d11f1678f7ad upstream.
This adds register fields for HDFGWTR2_EL2 as per the definitions based on DDI0601 2024-12.
--- arch/arm64/tools/sysreg | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
arch/arm64/tools/sysreg +28 -0
@@ -2494,6 +2494,34 @@ Field 1 nPMIAR_EL1 Field 0 nPMECR_EL1 EndSysreg +Sysreg HDFGWTR2_EL2 3 4 3 1 1 +Res0 63:25 +Field 24 nPMBMAR_EL1 +Field 23 nMDSTEPOP_EL1 +Field 22 nTRBMPAM_EL1 +Field 21 nPMZR_EL0 +Field 20 nTRCITECR_EL1 +Field 19 nPMSDSFR_EL1 +Res0 18:17 +Field 16 nSPMSCR_EL1 +Field 15 nSPMACCESSR_EL1 +Field 14 nSPMCR_EL0 +Field 13 nSPMOVS +Field 12 nSPMINTEN +Field 11 nSPMCNTEN +Field 10 nSPMSELR_EL0 +Field 9 nSPMEVTYPERn_EL0 +Field 8 nSPMEVCNTRn_EL0 +Field 7 nPMSSCR_EL1 +Res0 6 +Field 5 nMDSELR_EL1 +Field 4 nPMUACR_EL1 +Field 3 nPMICFILTR_EL0 +Field 2 nPMICNTR_EL0 +Field 1 nPMIAR_EL1 +Field 0 nPMECR_EL1 +EndSysreg + Sysreg HDFGRTR_EL2 3 4 3 1 4 Field 63 PMBIDR_EL1 Field 62 nPMSNEVFR_EL1
Greg Kroah-Hartman
maintainerPATCH 189/223 arm64/sysreg: Add register fields for HFGITR2_EL2
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
commit 9401476f17747586a8bfb29abfdf5ade7a8bceef upstream.
This adds register fields for HFGITR2_EL2 as per the definitions based on DDI0601 2024-12.
--- arch/arm64/tools/sysreg | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm64/tools/sysreg +6 -0
@@ -2694,6 +2694,12 @@ Field 1 AMEVCNTR00_EL0 Field 0 AMCNTEN0 EndSysreg +Sysreg HFGITR2_EL2 3 4 3 1 7 +Res0 63:2 +Field 1 nDCCIVAPS +Field 0 TSBCSYNC +EndSysreg + Sysreg ZCR_EL2 3 4 1 2 0 Fields ZCR_ELx EndSysreg
Greg Kroah-Hartman
maintainerPATCH 190/223 arm64/sysreg: Add register fields for HFGRTR2_EL2
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
commit 59236089ad5243377b6905d78e39ba4183dc35f5 upstream.
This adds register fields for HFGRTR2_EL2 as per the definitions based on DDI0601 2024-12.
--- arch/arm64/tools/sysreg | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
arch/arm64/tools/sysreg +19 -0
@@ -2522,6 +2522,25 @@ Field 1 nPMIAR_EL1 Field 0 nPMECR_EL1 EndSysreg +Sysreg HFGRTR2_EL2 3 4 3 1 2 +Res0 63:15 +Field 14 nACTLRALIAS_EL1 +Field 13 nACTLRMASK_EL1 +Field 12 nTCR2ALIAS_EL1 +Field 11 nTCRALIAS_EL1 +Field 10 nSCTLRALIAS2_EL1 +Field 9 nSCTLRALIAS_EL1 +Field 8 nCPACRALIAS_EL1 +Field 7 nTCR2MASK_EL1 +Field 6 nTCRMASK_EL1 +Field 5 nSCTLR2MASK_EL1 +Field 4 nSCTLRMASK_EL1 +Field 3 nCPACRMASK_EL1 +Field 2 nRCWSMASK_EL1 +Field 1 nERXGSR_EL1 +Field 0 nPFAR_EL1 +EndSysreg + Sysreg HDFGRTR_EL2 3 4 3 1 4 Field 63 PMBIDR_EL1 Field 62 nPMSNEVFR_EL1
Greg Kroah-Hartman
maintainerPATCH 191/223 arm64/sysreg: Add register fields for HFGWTR2_EL2
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
commit ea37be0773f04420515b8db49e50abedbaa97e23 upstream.
This adds register fields for HFGWTR2_EL2 as per the definitions based on DDI0601 2024-12.
--- arch/arm64/tools/sysreg | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+)
arch/arm64/tools/sysreg +19 -0
@@ -2541,6 +2541,25 @@ Field 1 nERXGSR_EL1 Field 0 nPFAR_EL1 EndSysreg +Sysreg HFGWTR2_EL2 3 4 3 1 3 +Res0 63:15 +Field 14 nACTLRALIAS_EL1 +Field 13 nACTLRMASK_EL1 +Field 12 nTCR2ALIAS_EL1 +Field 11 nTCRALIAS_EL1 +Field 10 nSCTLRALIAS2_EL1 +Field 9 nSCTLRALIAS_EL1 +Field 8 nCPACRALIAS_EL1 +Field 7 nTCR2MASK_EL1 +Field 6 nTCRMASK_EL1 +Field 5 nSCTLR2MASK_EL1 +Field 4 nSCTLRMASK_EL1 +Field 3 nCPACRMASK_EL1 +Field 2 nRCWSMASK_EL1 +Res0 1 +Field 0 nPFAR_EL1 +EndSysreg + Sysreg HDFGRTR_EL2 3 4 3 1 4 Field 63 PMBIDR_EL1 Field 62 nPMSNEVFR_EL1
Greg Kroah-Hartman
maintainerPATCH 192/223 arm64/boot: Enable EL2 requirements for FEAT_PMUv3p9
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anshuman Khandual <[email protected]>
commit 858c7bfcb35e1100b58bb63c9f562d86e09418d9 upstream.
FEAT_PMUv3p9 registers such as PMICNTR_EL0, PMICFILTR_EL0, and PMUACR_EL1 access from EL1 requires appropriate EL2 fine grained trap configuration via FEAT_FGT2 based trap control registers HDFGRTR2_EL2 and HDFGWTR2_EL2. Otherwise such register accesses will result in traps into EL2.
Add a new helper __init_el2_fgt2() which initializes FEAT_FGT2 based fine grained trap control registers HDFGRTR2_EL2 and HDFGWTR2_EL2 (setting the bits nPMICNTR_EL0, nPMICFILTR_EL0 and nPMUACR_EL1) to enable access into PMICNTR_EL0, PMICFILTR_EL0, and PMUACR_EL1 registers.
Also update booting.rst with SCR_EL3.FGTEn2 requirement for all FEAT_FGT2 based registers to be accessible in EL2.
--- Documentation/arch/arm64/booting.rst | 22 ++++++++++++++++++++++ arch/arm64/include/asm/el2_setup.h | 25 +++++++++++++++++++++++++ arch/arm64/tools/sysreg | 1 + 3 files changed, 48 insertions(+)
Documentation/arch/arm64/booting.rst +22 -0
@@ -285,6 +285,12 @@ Before jumping into the kernel, the foll - SCR_EL3.FGTEn (bit 27) must be initialised to 0b1. + For CPUs with the Fine Grained Traps 2 (FEAT_FGT2) extension present: + + - If EL3 is present and the kernel is entered at EL2: + + - SCR_EL3.FGTEn2 (bit 59) must be initialised to 0b1. + For CPUs with support for HCRX_EL2 (FEAT_HCX) present: - If EL3 is present and the kernel is entered at EL2:
@@ -379,6 +385,22 @@ Before jumping into the kernel, the foll - SMCR_EL2.EZT0 (bit 30) must be initialised to 0b1. + For CPUs with the Performance Monitors Extension (FEAT_PMUv3p9): + + - If EL3 is present: + + - MDCR_EL3.EnPM2 (bit 7) must be initialised to 0b1. + + - If the kernel is entered at EL1 and EL2 is present: + + - HDFGRTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1. + - HDFGRTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1. + - HDFGRTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1. + + - HDFGWTR2_EL2.nPMICNTR_EL0 (bit 2) must be initialised to 0b1. + - HDFGWTR2_EL2.nPMICFILTR_EL0 (bit 3) must be initialised to 0b1. + - HDFGWTR2_EL2.nPMUACR_EL1 (bit 4) must be initialised to 0b1. + For CPUs with Memory Copy and Memory Set instructions (FEAT_MOPS): - If the kernel is entered at EL1 and EL2 is present:
arch/arm64/include/asm/el2_setup.h +25 -0
@@ -215,6 +215,30 @@ .Lskip_fgt_\@: .endm +.macro __init_el2_fgt2 + mrs x1, id_aa64mmfr0_el1 + ubfx x1, x1, #ID_AA64MMFR0_EL1_FGT_SHIFT, #4 + cmp x1, #ID_AA64MMFR0_EL1_FGT_FGT2 + b.lt .Lskip_fgt2_\@ + +mov x0, xzr + mrs x1, id_aa64dfr0_el1 + ubfx x1, x1, #ID_AA64DFR0_EL1_PMUVer_SHIFT, #4 + cmp x1, #ID_AA64DFR0_EL1_PMUVer_V3P9 + b.lt .Lskip_pmuv3p9_\@ + + orr x0, x0, #HDFGRTR2_EL2_nPMICNTR_EL0 + orr x0, x0, #HDFGRTR2_EL2_nPMICFILTR_EL0 + orr x0, x0, #HDFGRTR2_EL2_nPMUACR_EL1 +.Lskip_pmuv3p9_\@: + msr_s SYS_HDFGRTR2_EL2, x0 + msr_s SYS_HDFGWTR2_EL2, x0 + msr_s SYS_HFGRTR2_EL2, xzr + msr_s SYS_HFGWTR2_EL2, xzr + msr_s SYS_HFGITR2_EL2, xzr +.Lskip_fgt2_\@: +.endm + .macro __init_el2_nvhe_prepare_eret mov x0, #INIT_PSTATE_EL1 msr spsr_el2, x0
@@ -240,6 +264,7 @@__init_el2_nvhe_idregs __init_el2_cptr __init_el2_fgt + __init_el2_fgt2 .endm#ifndef __KVM_NVHE_HYPERVISOR__
arch/arm64/tools/sysreg +1 -0
@@ -1238,6 +1238,7 @@ UnsignedEnum 11:8 PMUVer 0b0110 V3P5 0b0111 V3P7 0b1000 V3P8 + 0b1001 V3P9 0b1111 IMP_DEF EndEnum UnsignedEnum 7:4 TraceVer
Greg Kroah-Hartman
maintainerPATCH 193/223 cpufreq: Reference count policy in cpufreq_update_limits()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
commit 9e4e249018d208678888bdf22f6b652728106528 upstream.
Since acpi_processor_notify() can be called before registering a cpufreq driver or even in cases when a cpufreq driver is not registered at all, cpufreq_update_limits() needs to check if a cpufreq driver is present and prevent it from being unregistered.
For this purpose, make it call cpufreq_cpu_get() to obtain a cpufreq policy pointer for the given CPU and reference count the corresponding policy object, if present.
--- drivers/cpufreq/cpufreq.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/cpufreq/cpufreq.c +8 -0
@@ -2766,10 +2766,18 @@ EXPORT_SYMBOL(cpufreq_update_policy);*/ void cpufreq_update_limits (unsigned int cpu) { +struct cpufreq_policy *policy; + + policy =cpufreq_cpu_get (cpu); +if (!policy) +return ; +if (cpufreq_driver->update_limits) cpufreq_driver->update_limits (cpu);else cpufreq_update_policy (cpu); + +cpufreq_cpu_put (policy); }EXPORT_SYMBOL_GPL (cpufreq_update_limits);
Greg Kroah-Hartman
maintainerPATCH 194/223 scripts: generate_rust_analyzer: Add ffi crate
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Fischer <[email protected]>
commit 05a2b0011c4b6cbbc9b577f6abebe4e9333b0cf6 upstream.
Commit d072acda4862 ("rust: use custom FFI integer types") did not update rust-analyzer to include the new crate.
To enable rust-analyzer support for these custom ffi types, add the ffi crate as a dependency to the bindings, uapi and kernel crates, which all directly depend on it.
--- scripts/generate_rust_analyzer.py | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
scripts/generate_rust_analyzer.py +9 -3
@@ -90,6 +90,12 @@ def generate_crates(srctree, objtree, sy ["core", "compiler_builtins"], ) + append_crate( + "ffi", + srctree / "rust" / "ffi.rs", + ["core", "compiler_builtins"], + ) + def append_crate_with_generated( display_name, deps,
@@ -109,9 +115,9 @@ def generate_crates(srctree, objtree, sy "exclude_dirs": [], } - append_crate_with_generated("bindings", ["core"]) - append_crate_with_generated("uapi", ["core"]) - append_crate_with_generated("kernel", ["core", "macros", "build_error", "bindings", "uapi"]) + append_crate_with_generated("bindings", ["core", "ffi"]) + append_crate_with_generated("uapi", ["core", "ffi"]) + append_crate_with_generated("kernel", ["core", "macros", "build_error", "ffi", "bindings", "uapi"]) def is_root_crate(build_file, target): try:
Greg Kroah-Hartman
maintainerPATCH 195/223 kbuild: Add -fno-builtin-wcslen
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 84ffc79bfbf70c779e60218563f2f3ad45288671 upstream.
A recent optimization change in LLVM [1] aims to transform certain loop idioms into calls to strlen() or wcslen(). This change transforms the first while loop in UniStrcat() into a call to wcslen(), breaking the build when UniStrcat() gets inlined into alloc_path_with_tree_prefix():
ld.lld: error: undefined symbol: wcslen
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
referenced by nls_ucs2_utils.h:54 (
fs/smb/client/../../nls/nls_ucs2_utils.h:54)
vmlinux.o:(alloc_path_with_tree_prefix)
referenced by nls_ucs2_utils.h:54 (fs/smb/client/../../nls/nls_ucs2_utils.h:54)
vmlinux.o:(alloc_path_with_tree_prefix)
Disable this optimization with '-fno-builtin-wcslen', which prevents the compiler from assuming that wcslen() is available in the kernel's C library.
[ More to the point - it's not that we couldn't implement wcslen(), it's
that this isn't an optimization at all in the context of the kernel.
Replacing a simple inlined loop with a function call to the same loop is just stupid and pointless if you don't have long strings and fancy libraries with vectorization support etc.
For the regular 'strlen()' cases, we want the compiler to do this in order to handle the trivial case of constant strings. And we do have optimized versions of 'strlen()' on some architectures. But for
wcslen? Just no. - Linus ]
--- Makefile | 3 +++ 1 file changed, 3 insertions(+)
Makefile +3 -0
@@ -1015,6 +1015,9 @@ endif # Ensure compilers do not transform certain loops into calls to wcslen() KBUILD_CFLAGS += -fno-builtin-wcslen +# Ensure compilers do not transform certain loops into calls to wcslen() +KBUILD_CFLAGS += -fno-builtin-wcslen + # change __FILE__ to the relative path from the srctree KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
Greg Kroah-Hartman
maintainerPATCH 196/223 platform/x86: msi-wmi-platform: Rename "data" variable
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Armin Wolf <[email protected]>
commit 912d614ac99e137fd2016777e4b090c46ce84898 upstream.
Rename the "data" variable inside msi_wmi_platform_read() to avoid a name collision when the driver adds support for a state container struct (that is to be called "data" too) in the future.
--- drivers/platform/x86/msi-wmi-platform.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/platform/x86/msi-wmi-platform.c +4 -4
@@ -173,7 +173,7 @@ static int msi_wmi_platform_read(structstruct wmi_device *wdev =dev_get_drvdata (dev);u8 input[32 ] = {0 };u8 output[32 ]; -u16 data; +u16 value;int ret; ret = msi_wmi_platform_query(wdev, MSI_PLATFORM_GET_FAN, input, sizeof(input), output,
@@ -181,11 +181,11 @@ static int msi_wmi_platform_read(structif (ret <0 )return ret; - data =get_unaligned_be16 (&output[channel *2 +1 ]); -if (!data) + value =get_unaligned_be16 (&output[channel *2 +1 ]); +if (!value) *val =0 ;else - *val =480000 / data; + *val =480000 / value;return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 197/223 platform/x86: msi-wmi-platform: Workaround a ACPI firmware bug
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Armin Wolf <[email protected]>
commit baf2f2c2b4c8e1d398173acd4d2fa9131a86b84e upstream.
The ACPI byte code inside the ACPI control method responsible for handling the WMI method calls uses a global buffer for constructing the return value, yet the ACPI control method itself is not marked as "Serialized".
This means that calling WMI methods on this WMI device is not thread-safe, as concurrent WMI method calls will corrupt the global buffer.
Fix this by serializing the WMI method calls using a mutex.
--- Documentation/wmi/devices/msi-wmi-platform.rst | 4 + drivers/platform/x86/msi-wmi-platform.c | 91 ++++++++++++++++--------- 2 files changed, 63 insertions(+), 32 deletions(-)
Documentation/wmi/devices/msi-wmi-platform.rst +4 -0
@@ -138,6 +138,10 @@ input data, the meaning of which depends The output buffer contains a single byte which signals success or failure (``0x00`` on failure) and 31 bytes of output data, the meaning if which depends on the subfeature being accessed. +.. note:: + The ACPI control method responsible for handling the WMI method calls is not thread-safe. + This is a firmware bug that needs to be handled inside the driver itself. + WMI method Get_EC() -------------------
drivers/platform/x86/msi-wmi-platform.c +59 -32
241 lines not on this page · raw message
Greg Kroah-Hartman
maintainerPATCH 198/223 md: fix mddev uaf while iterating all_mddevs list
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yu Kuai <[email protected]>
commit 8542870237c3a48ff049b6c5df5f50c8728284fa upstream.
While iterating all_mddevs list from md_notify_reboot() and md_exit(), list_for_each_entry_safe is used, and this can race with deletint the next mddev, causing UAF:
t1:spin_lock
//list_for_each_entry_safe(mddev, n, ...)
mddev_get(mddev1)
// assume mddev2 is the next entry
spin_unlock
t2:
//remove mddev2
...
mddev_free
spin_lock
list_del
spin_unlock
kfree(mddev2) mddev_put(mddev1)
spin_lock
//continue dereference mddev2->all_mddevs
The old helper for_each_mddev() actually grab the reference of mddev2 while holding the lock, to prevent from being freed. This problem can be fixed the same way, however, the code will be complex.
Hence switch to use list_for_each_entry, in this case mddev_put() can free the mddev1 and it's not safe as well. Refer to md_seq_show(), also factor out a helper mddev_put_locked() to fix this problem.
--- drivers/md/md.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-)
drivers/md/md.c +13 -9
@@ -629,6 +629,12 @@ static void __mddev_put(struct mddev *mdqueue_work (md_misc_wq, &mddev->del_work); } +static void mddev_put_locked (struct mddev *mddev) +{ +if (atomic_dec_and_test (&mddev->active)) +__mddev_put (mddev); +} +void mddev_put (struct mddev *mddev) {if (!atomic_dec_and_lock (&mddev->active, &all_mddevs_lock))
@@ -8461,9 +8467,7 @@ static int md_seq_show(struct seq_file * if (mddev == list_last_entry(&all_mddevs, struct mddev, all_mddevs))status_unused (seq); -if (atomic_dec_and_test (&mddev->active)) -__mddev_put (mddev); - +mddev_put_locked (mddev);return 0 ; }
@@ -9886,11 +9890,11 @@ EXPORT_SYMBOL_GPL(rdev_clear_badblocks);static int md_notify_reboot (struct notifier_block *this,unsigned long code,void *x) { -struct mddev *mddev, *n; +struct mddev *mddev;int need_delay =0 ;spin_lock (&all_mddevs_lock); -list_for_each_entry_safe (mddev, n, &all_mddevs, all_mddevs) { +list_for_each_entry (mddev, &all_mddevs, all_mddevs) {if (!mddev_get (mddev))continue ;spin_unlock (&all_mddevs_lock);
@@ -9902,8 +9906,8 @@ static int md_notify_reboot(struct notifmddev_unlock (mddev); } need_delay =1 ; -mddev_put (mddev);spin_lock (&all_mddevs_lock); +mddev_put_locked (mddev); }spin_unlock (&all_mddevs_lock);
@@ -10236,7 +10240,7 @@ void md_autostart_arrays(int part) static __exit void md_exit(void) { -struct mddev *mddev, *n; +struct mddev *mddev;int delay =1 ;unregister_blkdev (MD_MAJOR ,"md" );
@@ -10257,7 +10261,7 @@ static __exit void md_exit(void)remove_proc_entry ("mdstat" ,NULL );spin_lock (&all_mddevs_lock); -list_for_each_entry_safe (mddev, n, &all_mddevs, all_mddevs) { +list_for_each_entry (mddev, &all_mddevs, all_mddevs) {if (!mddev_get (mddev))continue ;spin_unlock (&all_mddevs_lock);
@@ -10269,8 +10273,8 @@ static __exit void md_exit(void)* the mddev for destruction by a workqueue, and the * destroy_workqueue() below will wait for that to complete. */ -mddev_put (mddev);spin_lock (&all_mddevs_lock); +mddev_put_locked (mddev); }spin_unlock (&all_mddevs_lock);
Greg Kroah-Hartman
maintainerPATCH 199/223 selftests/bpf: Fix raw_tp null handling test
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shung-Hsi Yu <[email protected]>
Commit b2fc4b17fc13, backport of upstream commit 838a10bd2ebf ("bpf:
Augment raw_tp arguments with PTR_MAYBE_NULL"), was missing the changes to tools/testing/selftests/bpf/progs/raw_tp_null.c, and cause the test to fail with the following error (see link below for the complete log)
Error: #205 raw_tp_null
libbpf: prog 'test_raw_tp_null': BPF program load failed: Permission denied
libbpf: prog 'test_raw_tp_null': -- BEGIN PROG LOAD LOG --
0: R1=ctx() R10=fp0
; int BPF_PROG(test_raw_tp_null, struct sk_buff *skb) @ raw_tp_null.c:13 0: (79) r6 = *(u64 *)(r1 +0)
func 'bpf_testmod_test_raw_tp_null' arg0 has btf_id 2081 type STRUCT 'sk_buff' 1: R1=ctx() R6_w=trusted_ptr_or_null_sk_buff(id=1)
; struct task_struct *task = bpf_get_current_task_btf(); @ raw_tp_null.c:15
1: (85) call bpf_get_current_task_btf#158 ; R0_w=trusted_ptr_task_struct()
; if (task->pid != tid) @ raw_tp_null.c:17
2: (61) r1 = *(u32 *)(r0 +1416) ; R0_w=trusted_ptr_task_struct() R1_w=scalar(smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff)) 3: (18) r2 = 0xffffa3bb801c6000 ; R2_w=map_value(map=raw_tp_n.bss,ks=4,vs=8) 5: (61) r2 = *(u32 *)(r2 +0) ; R2_w=scalar(smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff)) 6: (5e) if w1 != w2 goto pc+11 ; R1_w=scalar(smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff)) R2_w=scalar(smin=0,smax=umax=0xffffffff,var_off=(0x0; 0xffffffff))
; i = i + skb->mark + 1; @ raw_tp_null.c:20
7: (61) r2 = *(u32 *)(r6 +164)
R6 invalid mem access 'trusted_ptr_or_null_'
processed 7 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 -- END PROG LOAD LOG --
libbpf: prog 'test_raw_tp_null': failed to load: -13
libbpf: failed to load object 'raw_tp_null'
libbpf: failed to load BPF skeleton 'raw_tp_null': -13 test_raw_tp_null:FAIL:raw_tp_null__open_and_load unexpected error: -13
Bring the missing changes in to fix the test failure.
--- tools/testing/selftests/bpf/progs/raw_tp_null.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-)
tools/testing/selftests/bpf/progs/raw_tp_null.c +9 -10
@@ -3,6 +3,7 @@#include <vmlinux.h> #include <bpf/bpf_tracing.h> +#include "bpf_misc.h" char _license[] SEC("license") = "GPL";
@@ -17,16 +18,14 @@ int BPF_PROG(test_raw_tp_null, struct skif (task->pid != tid)return 0 ; - i = i + skb->mark +1 ; -/* The compiler may move the NULL check before this deref, which causes -* the load to fail as deref of scalar. Prevent that by using a barrier. +/* If dead code elimination kicks in, the increment +=2 will be +* removed. For raw_tp programs attaching to tracepoints in kernel +* modules, we mark input arguments as PTR_MAYBE_NULL, so branch +* prediction should never kick in. */ -barrier (); -/* If dead code elimination kicks in, the increment below will -* be removed. For raw_tp programs, we mark input arguments as -* PTR_MAYBE_NULL, so branch prediction should never kick in. -*/ -if (!skb) - i +=2 ; + asmvolatile ("%[i] += 1; if %[ctx] != 0 goto +1; %[i] += 2;" + : [i]"+r" (i) + : [ctx]"r" (skb) + :"memory" );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 200/223 misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq error
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kunihiko Hayashi <[email protected]>
commit f6cb7828c8e17520d4f5afb416515d3fae1af9a9 upstream.
After devm_request_irq() fails with error in pci_endpoint_test_request_irq(), the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQs have been released.
However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message:
remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0'
WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19c
To solve this issue, set the number of remaining IRQs to test->num_irqs, and release IRQs in advance by calling pci_endpoint_test_release_irq().
--- drivers/misc/pci_endpoint_test.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/misc/pci_endpoint_test.c +3 -0
@@ -251,6 +251,9 @@ fail:break ; } + test->num_irqs = i; +pci_endpoint_test_release_irq (test); +return false; }
Greg Kroah-Hartman
maintainerPATCH 201/223 misc: pci_endpoint_test: Fix irq_type to convey the correct type
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kunihiko Hayashi <[email protected]>
commit baaef0a274cfb75f9b50eab3ef93205e604f662c upstream.
There are two variables that indicate the interrupt type to be used in the next test execution, "irq_type" as global and "test->irq_type".
The global is referenced from pci_endpoint_test_get_irq() to preserve the current type for ioctl(PCITEST_GET_IRQTYPE).
The type set in this function isn't reflected in the global "irq_type", so ioctl(PCITEST_GET_IRQTYPE) returns the previous type.
As a result, the wrong type is displayed in old version of "pcitest" as follows:
- Result of running "pcitest -i 0"
SET IRQ TYPE TO LEGACY: OKAY
- Result of running "pcitest -I"
GET IRQ TYPE: MSI
Whereas running the new version of "pcitest" in kselftest results in an error as follows:
# RUN pci_ep_basic.LEGACY_IRQ_TEST ...
# pci_endpoint_test.c:104:LEGACY_IRQ_TEST:Expected 0 (0) == ret (1) # pci_endpoint_test.c:104:LEGACY_IRQ_TEST:Can't get Legacy IRQ type
Fix this issue by propagating the current type to the global "irq_type".
--- drivers/misc/pci_endpoint_test.c | 1 + 1 file changed, 1 insertion(+)
drivers/misc/pci_endpoint_test.c +1 -0
@@ -741,6 +741,7 @@ static bool pci_endpoint_test_set_irq(stif (!pci_endpoint_test_request_irq (test)) goto err; + irq_type = test->irq_type;return true; err:
Greg Kroah-Hartman
maintainerPATCH 202/223 efi/libstub: Bump up EFI_MMAP_NR_SLACK_SLOTS to 32
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hamza Mahfooz <[email protected]>
commit ec4696925da6b9baec38345184403ce9e29a2e48 upstream.
Recent platforms require more slack slots than the current value of EFI_MMAP_NR_SLACK_SLOTS, otherwise they fail to boot. The current workaround is to append efi=disable_early_pci_dma to the kernel's cmdline. So, bump up EFI_MMAP_NR_SLACK_SLOTS to 32 to allow those platforms to boot with the aforementioned workaround.
--- drivers/firmware/efi/libstub/efistub.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/firmware/efi/libstub/efistub.h +1 -1
@@ -171,7 +171,7 @@ void efi_set_u64_split(u64 data, u32 *lo* the EFI memory map. Other related structures, e.g. x86 e820ext, need * to factor in this headroom requirement as well. */ -#define EFI_MMAP_NR_SLACK_SLOTS 8 +#define EFI_MMAP_NR_SLACK_SLOTS 32typedef struct efi_generic_dev_path efi_device_path_protocol_t ;
Greg Kroah-Hartman
maintainerPATCH 203/223 LoongArch: Eliminate superfluous get_numa_distances_cnt()
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yuli Wang <[email protected]>
commit a0d3c8bcb9206ac207c7ad3182027c6b0a1319bb upstream.
In LoongArch, get_numa_distances_cnt() isn't in use, resulting in a compiler warning.
Fix follow errors with clang-18 when W=1e:
arch/loongarch/kernel/acpi.c:259:28: error: unused function 'get_numa_distances_cnt' [-Werror,-Wunused-function]
259 | static inline unsigned int get_numa_distances_cnt(struct acpi_table_slit *slit)
| ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
--- arch/loongarch/kernel/acpi.c | 12 ------------ 1 file changed, 12 deletions(-)
arch/loongarch/kernel/acpi.c +0 -12
@@ -249,18 +249,6 @@ static __init int setup_node(int pxm)return acpi_map_pxm_to_node (pxm); } -/* -* Callback for SLIT parsing. pxm_to_node() returns NUMA_NO_NODE for -* I/O localities since SRAT does not list them. I/O localities are -* not supported at this point. -*/ -unsigned int numa_distance_cnt; - -static inline unsigned int get_numa_distances_cnt (struct acpi_table_slit *slit) -{ -return slit->locality_count; -} -void __init numa_set_distance (int from,int to,int distance) {if ((u8 )distance != distance || (from == to && distance !=LOCAL_DISTANCE )) {
Greg Kroah-Hartman
maintainerPATCH 204/223 drm/amd/display: Temporarily disable hostvm on DCN31
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aurabindo Pillai <[email protected]>
commit ba93dddfc92084a1e28ea447ec4f8315f3d8d3fd upstream.
With HostVM enabled, DCN31 fails to pass validation for 3x4k60. Some Linux userspace does not downgrade one of the monitors to 4k30, and the result is that the monitor does not light up. Disable it until the bandwidth calculation failure is resolved.
--- drivers/gpu/drm/amd/display/dc/resource/dcn31/dcn31_resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/display/dc/resource/dcn31/dcn31_resource.c +1 -1
@@ -891,7 +891,7 @@ static const struct dc_debug_options deb .disable_z10 = true, .enable_legacy_fast_update = true, .enable_z9_disable_interface = true, /* Allow support for the PMFW interface for disable Z9*/ - .dml_hostvm_override = DML_HOSTVM_NO_OVERRIDE, + .dml_hostvm_override = DML_HOSTVM_OVERRIDE_FALSE, .using_dml2 = false, };
Greg Kroah-Hartman
maintainerPATCH 205/223 nvmet-fc: Remove unused functions
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: WangYuli <[email protected]>
commit 1b304c006b0fb4f0517a8c4ba8c46e88f48a069c upstream.
The functions nvmet_fc_iodnum() and nvmet_fc_fodnum() are currently unutilized.
Following commit c53432030d86 ("nvme-fabrics: Add target support for FC transport"), which introduced these two functions, they have not been used at all in practice.
Remove them to resolve the compiler warnings.
Fix follow errors with clang-19 when W=1e:
drivers/nvme/target/fc.c:177:1: error: unused function 'nvmet_fc_iodnum' [-Werror,-Wunused-function]
177 | nvmet_fc_iodnum(struct nvmet_fc_ls_iod *iodptr)
| ^~~~~~~~~~~~~~~
drivers/nvme/target/fc.c:183:1: error: unused function 'nvmet_fc_fodnum' [-Werror,-Wunused-function]
183 | nvmet_fc_fodnum(struct nvmet_fc_fcp_iod *fodptr)
| ^~~~~~~~~~~~~~~
2 errors generated.
make[8]: *** [scripts/Makefile.build:207: drivers/nvme/target/fc.o] Error 1 make[7]: *** [scripts/Makefile.build:465: drivers/nvme/target] Error 2
make[6]: *** [scripts/Makefile.build:465: drivers/nvme] Error 2
make[6]: *** Waiting for unfinished jobs....
--- drivers/nvme/target/fc.c | 14 -------------- 1 file changed, 14 deletions(-)
drivers/nvme/target/fc.c +0 -14
@@ -172,20 +172,6 @@ struct nvmet_fc_tgt_assoc {struct work_struct del_work; }; - -static inline int -nvmet_fc_iodnum (struct nvmet_fc_ls_iod *iodptr) -{ -return (iodptr - iodptr->tgtport->iod); -} - -static inline int -nvmet_fc_fodnum (struct nvmet_fc_fcp_iod *fodptr) -{ -return (fodptr - fodptr->queue->fod); -} - -/* * Association and Connection IDs: *
Greg Kroah-Hartman
maintainerPATCH 206/223 block: remove rq_list_move
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
commit e8225ab15006fbcdb14cef426a0a54475292fbbc upstream.
Unused now.
--- include/linux/blk-mq.h | 17 ----------------- 1 file changed, 17 deletions(-)
include/linux/blk-mq.h +0 -17
@@ -270,23 +270,6 @@ static inline unsigned short req_get_iop#define rq_list_empty (list) ((list) == (struct request *) NULL)/** -* rq_list_move() - move a struct request from one list to another -* @src: The source list @rq is currently in -* @dst: The destination list that @rq will be appended to -* @rq: The request to move -* @prev: The request preceding @rq in @src (NULL if @rq is the head) -*/ -static inline void rq_list_move (struct request **src,struct request **dst, -struct request *rq,struct request *prev) -{ -if (prev) - prev->rq_next = rq->rq_next; -else - *src = rq->rq_next; -rq_list_add (dst, rq); -} - -/** * enum blk_eh_timer_return - How the timeout handler should proceed * @BLK_EH_DONE: The block driver completed the command or will complete it at * a later time.
Greg Kroah-Hartman
maintainerPATCH 207/223 block: add a rq_list type
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
commit a3396b99990d8b4e5797e7b16fdeb64c15ae97bb upstream.
Replace the semi-open coded request list helpers with a proper rq_list type that mirrors the bio_list and has head and tail pointers. Besides better type safety this actually allows to insert at the tail of the list, which will be useful soon.
--- block/blk-core.c | 6 +- block/blk-merge.c | 2 block/blk-mq.c | 40 +++++++++---------- block/blk-mq.h | 2 drivers/block/null_blk/main.c | 9 +--- drivers/block/virtio_blk.c | 13 ++---- drivers/nvme/host/apple.c | 2 drivers/nvme/host/pci.c | 15 +++---- include/linux/blk-mq.h | 88 ++++++++++++++++++++++++------------------ include/linux/blkdev.h | 11 +++-- io_uring/rw.c | 4 - 11 files changed, 104 insertions(+), 88 deletions(-)
block/blk-core.c +3 -3
@@ -1121,8 +1121,8 @@ void blk_start_plug_nr_ios(struct blk_plreturn ; plug->cur_ktime =0 ; - plug->mq_list =NULL ; - plug->cached_rq =NULL ; +rq_list_init (&plug->mq_list); +rq_list_init (&plug->cached_rqs); plug->nr_ios = min_t(unsigned short, nr_ios, BLK_MAX_REQUEST_COUNT); plug->rq_count =0 ; plug->multiple_queues = false;
@@ -1218,7 +1218,7 @@ void __blk_flush_plug(struct blk_plug *p* queue for cached requests, we don't want a blocked task holding * up a queue freeze/quiesce event. */ -if (unlikely (!rq_list_empty (plug->cached_rq))) +if (unlikely (!rq_list_empty (&plug->cached_rqs)))blk_mq_free_plug_rqs (plug); plug->cur_ktime =0 ;
block/blk-merge.c +1 -1
@@ -1175,7 +1175,7 @@ bool blk_attempt_plug_merge(struct requestruct blk_plug *plug = current->plug;struct request *rq; -if (!plug ||rq_list_empty (plug->mq_list)) +if (!plug ||rq_list_empty (&plug->mq_list))return false;rq_list_for_each (&plug->mq_list, rq) {
block/blk-mq.c +19 -21
@@ -506,7 +506,7 @@ __blk_mq_alloc_requests_batch(struct blkprefetch (tags->static_rqs[tag]); tag_mask &= ~(1UL << i); rq =blk_mq_rq_ctx_init (data, tags, tag); -rq_list_add (data->cached_rq, rq); +rq_list_add_head (data->cached_rqs, rq); nr++; }if (!(data->rq_flags &RQF_SCHED_TAGS ))
@@ -515,7 +515,7 @@ __blk_mq_alloc_requests_batch(struct blkpercpu_ref_get_many (&data->q->q_usage_counter, nr -1 ); data->nr_tags -= nr; -return rq_list_pop (data->cached_rq); +return rq_list_pop (data->cached_rqs); }static struct request *__blk_mq_alloc_requests (struct blk_mq_alloc_data *data)
@@ -612,7 +612,7 @@ static struct request *blk_mq_rq_cache_f .flags = flags, .cmd_flags = opf, .nr_tags = plug->nr_ios, - .cached_rq = &plug->cached_rq, + .cached_rqs = &plug->cached_rqs, };struct request *rq;
@@ -637,14 +637,14 @@ static struct request *blk_mq_alloc_cachif (!plug)return NULL ; -if (rq_list_empty (plug->cached_rq)) { +if (rq_list_empty (&plug->cached_rqs)) {if (plug->nr_ios ==1 )return NULL ; rq =blk_mq_rq_cache_fill (q, plug, opf, flags);if (!rq)return NULL ; }else { - rq =rq_list_peek (&plug->cached_rq); + rq =rq_list_peek (&plug->cached_rqs);if (!rq || rq->q != q)return NULL ;
@@ -653,7 +653,7 @@ static struct request *blk_mq_alloc_cachif (op_is_flush (rq->cmd_flags) !=op_is_flush (opf))return NULL ; - plug->cached_rq =rq_list_next (rq); +rq_list_pop (&plug->cached_rqs);blk_mq_rq_time_init (rq,0 ); }
@@ -830,7 +830,7 @@ void blk_mq_free_plug_rqs(struct blk_plu {struct request *rq; -while ((rq =rq_list_pop (&plug->cached_rq)) !=NULL ) +while ((rq =rq_list_pop (&plug->cached_rqs)) !=NULL )blk_mq_free_request (rq); }
@@ -1386,8 +1386,7 @@ static void blk_add_rq_to_plug(struct bl*/ if (!plug->has_elevator && (rq->rq_flags &RQF_SCHED_TAGS )) plug->has_elevator = true; - rq->rq_next =NULL ; -rq_list_add (&plug->mq_list, rq); +rq_list_add_head (&plug->mq_list, rq); plug->rq_count++; }
@@ -2781,7 +2780,7 @@ static void blk_mq_plug_issue_direct(strblk_status_t ret =BLK_STS_OK ;while ((rq =rq_list_pop (&plug->mq_list))) { -bool last =rq_list_empty (plug->mq_list); +bool last =rq_list_empty (&plug->mq_list);if (hctx != rq->mq_hctx) {if (hctx) {
@@ -2824,8 +2823,7 @@ static void blk_mq_dispatch_plug_list(st {struct blk_mq_hw_ctx *this_hctx =NULL ;struct blk_mq_ctx *this_ctx =NULL ; -struct request *requeue_list =NULL ; -struct request **requeue_lastp = &requeue_list; +struct rq_list requeue_list = {};unsigned int depth =0 ;bool is_passthrough = false;LIST_HEAD (list);
@@ -2839,12 +2837,12 @@ static void blk_mq_dispatch_plug_list(st is_passthrough =blk_rq_is_passthrough (rq); }else if (this_hctx != rq->mq_hctx || this_ctx != rq->mq_ctx || is_passthrough !=blk_rq_is_passthrough (rq)) { -rq_list_add_tail (&requeue_lastp, rq); +rq_list_add_tail (&requeue_list, rq);continue ; }list_add (&rq->queuelist, &list); depth++; - }while (!rq_list_empty (plug->mq_list)); + }while (!rq_list_empty (&plug->mq_list)); plug->mq_list = requeue_list;trace_block_unplug (this_hctx->queue, depth, !from_sched);
@@ -2899,19 +2897,19 @@ void blk_mq_flush_plug_list(struct blk_pif (q->mq_ops->queue_rqs) {blk_mq_run_dispatch_ops (q,__blk_mq_flush_plug_list (q, plug)); -if (rq_list_empty (plug->mq_list)) +if (rq_list_empty (&plug->mq_list))return ; }blk_mq_run_dispatch_ops (q,blk_mq_plug_issue_direct (plug)); -if (rq_list_empty (plug->mq_list)) +if (rq_list_empty (&plug->mq_list))return ; }do {blk_mq_dispatch_plug_list (plug, from_schedule); - }while (!rq_list_empty (plug->mq_list)); + }while (!rq_list_empty (&plug->mq_list)); } static void blk_mq_try_issue_list_directly(struct blk_mq_hw_ctx *hctx,
@@ -2976,7 +2974,7 @@ static struct request *blk_mq_get_new_reif (plug) { data.nr_tags = plug->nr_ios; plug->nr_ios =1 ; - data.cached_rq = &plug->cached_rq; + data.cached_rqs = &plug->cached_rqs; } rq =__blk_mq_alloc_requests (&data);
@@ -2999,7 +2997,7 @@ static struct request *blk_mq_peek_cacheif (!plug)return NULL ; - rq =rq_list_peek (&plug->cached_rq); + rq =rq_list_peek (&plug->cached_rqs);if (!rq || rq->q != q)return NULL ; if (type != rq->mq_hctx->type &&
@@ -3013,14 +3011,14 @@ static struct request *blk_mq_peek_cachestatic void blk_mq_use_cached_rq (struct request *rq,struct blk_plug *plug,struct bio *bio) { -WARN_ON_ONCE (rq_list_peek (&plug->cached_rq) != rq); +if (rq_list_pop (&plug->cached_rqs) != rq) +WARN_ON_ONCE (1 );/* * If any qos ->throttle() end up blocking, we will have flushed the * plug and hence killed the cached_rq list as well. Pop this entry * before we throttle. */ - plug->cached_rq =rq_list_next (rq);rq_qos_throttle (rq->q, bio);blk_mq_rq_time_init (rq,0 );
block/blk-mq.h +1 -1
@@ -155,7 +155,7 @@ struct blk_mq_alloc_data {/* allocate multiple requests/tags in one go */ unsigned int nr_tags; -struct request **cached_rq; +struct rq_list *cached_rqs;/* input & output parameter */ struct blk_mq_ctx *ctx;
drivers/block/null_blk/main.c +4 -5
@@ -1638,10 +1638,9 @@ static blk_status_t null_queue_rq(structreturn BLK_STS_OK ; } -static void null_queue_rqs (struct request **rqlist) +static void null_queue_rqs (struct rq_list *rqlist) { -struct request *requeue_list =NULL ; -struct request **requeue_lastp = &requeue_list; +struct rq_list requeue_list = {};struct blk_mq_queue_data bd = { };blk_status_t ret;
@@ -1651,8 +1650,8 @@ static void null_queue_rqs(struct reques bd.rq = rq; ret =null_queue_rq (rq->mq_hctx, &bd);if (ret !=BLK_STS_OK ) -rq_list_add_tail (&requeue_lastp, rq); - }while (!rq_list_empty (*rqlist)); +rq_list_add_tail (&requeue_list, rq); + }while (!rq_list_empty (rqlist)); *rqlist = requeue_list; }
drivers/block/virtio_blk.c +6 -7
@@ -472,7 +472,7 @@ static bool virtblk_prep_rq_batch(struct }static void virtblk_add_req_batch (struct virtio_blk_vq *vq, -struct request **rqlist) +struct rq_list *rqlist) {struct request *req;unsigned long flags;
@@ -499,11 +499,10 @@ static void virtblk_add_req_batch(structvirtqueue_notify (vq->vq); } -static void virtio_queue_rqs (struct request **rqlist) +static void virtio_queue_rqs (struct rq_list *rqlist) { -struct request *submit_list =NULL ; -struct request *requeue_list =NULL ; -struct request **requeue_lastp = &requeue_list; +struct rq_list submit_list = { }; +struct rq_list requeue_list = { };struct virtio_blk_vq *vq =NULL ;struct request *req;
@@ -515,9 +514,9 @@ static void virtio_queue_rqs(struct requ vq = this_vq;if (virtblk_prep_rq_batch (req)) -rq_list_add (&submit_list, req);/* reverse order */ +rq_list_add_head (&submit_list, req);/* reverse order */ else -rq_list_add_tail (&requeue_lastp, req); +rq_list_add_tail (&requeue_list, req); }if (vq)
drivers/nvme/host/apple.c +1 -1
@@ -650,7 +650,7 @@ static bool apple_nvme_handle_cq(struct found =apple_nvme_poll_cq (q, &iob); -if (!rq_list_empty (iob.req_list)) +if (!rq_list_empty (&iob.req_list))apple_nvme_complete_batch (&iob);return found;
drivers/nvme/host/pci.c +7 -8
@@ -985,7 +985,7 @@ static blk_status_t nvme_queue_rq(structreturn BLK_STS_OK ; } -static void nvme_submit_cmds (struct nvme_queue *nvmeq,struct request **rqlist) +static void nvme_submit_cmds (struct nvme_queue *nvmeq,struct rq_list *rqlist) {struct request *req;
@@ -1013,11 +1013,10 @@ static bool nvme_prep_rq_batch(struct nvreturn nvme_prep_rq (nvmeq->dev, req) ==BLK_STS_OK ; } -static void nvme_queue_rqs (struct request **rqlist) +static void nvme_queue_rqs (struct rq_list *rqlist) { -struct request *submit_list =NULL ; -struct request *requeue_list =NULL ; -struct request **requeue_lastp = &requeue_list; +struct rq_list submit_list = { }; +struct rq_list requeue_list = { };struct nvme_queue *nvmeq =NULL ;struct request *req;
@@ -1027,9 +1026,9 @@ static void nvme_queue_rqs(struct reques nvmeq = req->mq_hctx->driver_data;if (nvme_prep_rq_batch (nvmeq, req)) -rq_list_add (&submit_list, req);/* reverse order */ +rq_list_add_head (&submit_list, req);/* reverse order */ else -rq_list_add_tail (&requeue_lastp, req); +rq_list_add_tail (&requeue_list, req); }if (nvmeq)
@@ -1176,7 +1175,7 @@ static irqreturn_t nvme_irq(int irq, voiDEFINE_IO_COMP_BATCH (iob);if (nvme_poll_cq (nvmeq, &iob)) { -if (!rq_list_empty (iob.req_list)) +if (!rq_list_empty (&iob.req_list))nvme_pci_complete_batch (&iob);return IRQ_HANDLED ; }
include/linux/blk-mq.h +52 -36
110 lines not on this page · raw message
include/linux/blkdev.h +8 -3
@@ -996,6 +996,11 @@ extern void blk_put_queue(struct requestvoid blk_mark_disk_dead (struct gendisk *disk);#ifdef CONFIG_BLOCK +struct rq_list { +struct request *head; +struct request *tail; +}; +/* * blk_plug permits building a queue of related requests by holding the I/O * fragments for a short period. This allows merging of sequential requests
@@ -1008,10 +1013,10 @@ void blk_mark_disk_dead(struct gendisk ** blk_flush_plug() is called. */ struct blk_plug { -struct request *mq_list;/* blk-mq requests */ +struct rq_list mq_list;/* blk-mq requests */ /* if ios_left is > 1, we can batch tag/rq allocations */ -struct request *cached_rq; +struct rq_list cached_rqs;u64 cur_ktime;unsigned short nr_ios;
@@ -1660,7 +1665,7 @@ int bdev_thaw(struct block_device *bdev)void bdev_fput (struct file *bdev_file);struct io_comp_batch { -struct request *req_list; +struct rq_list req_list;bool need_ts;void (*complete)(struct io_comp_batch *); };
io_uring/rw.c +2 -2
@@ -1190,12 +1190,12 @@ int io_do_iopoll(struct io_ring_ctx *ctx poll_flags |=BLK_POLL_ONESHOT ;/* iopoll may have completed current req */ -if (!rq_list_empty (iob.req_list) || +if (!rq_list_empty (&iob.req_list) ||READ_ONCE (req->iopoll_completed))break ; } -if (!rq_list_empty (iob.req_list)) +if (!rq_list_empty (&iob.req_list)) iob.complete (&iob);else if (!pos)return 0 ;
Greg Kroah-Hartman
maintainerPATCH 208/223 block: dont reorder requests in blk_add_rq_to_plug
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christoph Hellwig <[email protected]>
commit e70c301faece15b618e54b613b1fd6ece3dd05b4 upstream.
Add requests to the tail of the list instead of the front so that they are queued up in submission order.
Remove the re-reordering in blk_mq_dispatch_plug_list, virtio_queue_rqs and nvme_queue_rqs now that the list is ordered as expected.
--- block/blk-mq.c | 4 ++-- drivers/block/virtio_blk.c | 2 +- drivers/nvme/host/pci.c | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-)
block/blk-mq.c +2 -2
@@ -1386,7 +1386,7 @@ static void blk_add_rq_to_plug(struct bl*/ if (!plug->has_elevator && (rq->rq_flags &RQF_SCHED_TAGS )) plug->has_elevator = true; -rq_list_add_head (&plug->mq_list, rq); +rq_list_add_tail (&plug->mq_list, rq); plug->rq_count++; }
@@ -2840,7 +2840,7 @@ static void blk_mq_dispatch_plug_list(strq_list_add_tail (&requeue_list, rq);continue ; } -list_add (&rq->queuelist, &list); +list_add_tail (&rq->queuelist, &list); depth++; }while (!rq_list_empty (&plug->mq_list));
drivers/block/virtio_blk.c +1 -1
@@ -514,7 +514,7 @@ static void virtio_queue_rqs(struct rq_l vq = this_vq;if (virtblk_prep_rq_batch (req)) -rq_list_add_head (&submit_list, req);/* reverse order */ +rq_list_add_tail (&submit_list, req);else rq_list_add_tail (&requeue_list, req); }
drivers/nvme/host/pci.c +1 -1
@@ -1026,7 +1026,7 @@ static void nvme_queue_rqs(struct rq_lis nvmeq = req->mq_hctx->driver_data;if (nvme_prep_rq_batch (nvmeq, req)) -rq_list_add_head (&submit_list, req);/* reverse order */ +rq_list_add_tail (&submit_list, req);else rq_list_add_tail (&requeue_list, req); }
Greg Kroah-Hartman
maintainerPATCH 209/223 mm/vma: add give_up_on_oom option on modify/merge, use in uffd release
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lorenzo Stoakes <[email protected]>
commit 41e6ddcaa0f18dda4c3fadf22533775a30d6f72f upstream.
Currently, if a VMA merge fails due to an OOM condition arising on commit merge or a failure to duplicate anon_vma's, we report this so the caller can handle it.
However there are cases where the caller is only ostensibly trying a merge, and doesn't mind if it fails due to this condition.
Since we do not want to introduce an implicit assumption that we only actually modify VMAs after OOM conditions might arise, add a 'give up on oom' option and make an explicit contract that, should this flag be set, we absolutely will not modify any VMAs should OOM arise and just bail out.
Since it'd be very unusual for a user to try to vma_modify() with this flag set but be specifying a range within a VMA which ends up being split (which can fail due to rlimit issues, not only OOM), we add a debug warning for this condition.
The motivating reason for this is uffd release - syzkaller (and Pedro Falcato's VERY astute analysis) found a way in which an injected fault on allocation, triggering an OOM condition on commit merge, would result in uffd code becoming confused and treating an error value as if it were a VMA pointer.
To avoid this, we make use of this new VMG flag to ensure that this never occurs, utilising the fact that, should we be clearing entire VMAs, we do not wish an OOM event to be reported to us.
Many thanks to Pedro Falcato for his excellent analysis and Jann Horn for his insightful and intelligent analysis of the situation, both of whom were instrumental in this fix.
--- mm/userfaultfd.c | 13 +++++++++++-- mm/vma.c | 38 ++++++++++++++++++++++++++++++++++---- mm/vma.h | 9 ++++++++- 3 files changed, 53 insertions(+), 7 deletions(-)
mm/userfaultfd.c +11 -2
@@ -1873,6 +1873,14 @@ struct vm_area_struct *userfaultfd_clear unsigned long end) {struct vm_area_struct *ret; +bool give_up_on_oom = false; + +/* +* If we are modifying only and not splitting, just give up on the merge +* if OOM prevents us from merging successfully. +*/ +if (start == vma->vm_start && end == vma->vm_end) + give_up_on_oom = true;/* Reset ptes for the whole vma range if wr-protected */ if (userfaultfd_wp (vma))
@@ -1880,7 +1888,7 @@ struct vm_area_struct *userfaultfd_clear ret =vma_modify_flags_uffd (vmi, prev, vma, start, end, vma->vm_flags & ~__VM_UFFD_FLAGS, -NULL_VM_UFFD_CTX ); +NULL_VM_UFFD_CTX , give_up_on_oom);/* * In the vma_merge() successful mprotect-like case 8:
@@ -1931,7 +1939,8 @@ int userfaultfd_register_range(struct us new_flags = (vma->vm_flags & ~__VM_UFFD_FLAGS) | vm_flags; vma =vma_modify_flags_uffd (&vmi, prev, vma, start, vma_end, new_flags, - (struct vm_userfaultfd_ctx ){ctx}); + (struct vm_userfaultfd_ctx ){ctx}, +/* give_up_on_oom = */ false);if (IS_ERR (vma))return PTR_ERR (vma);
mm/vma.c +34 -4
@@ -846,7 +846,13 @@ static struct vm_area_struct *vma_merge_if (anon_dup)unlink_anon_vmas (anon_dup); - vmg->state =VMA_MERGE_ERROR_NOMEM ; +/* +* We've cleaned up any cloned anon_vma's, no VMAs have been +* modified, no harm no foul if the user requests that we not +* report this and just give up, leaving the VMAs unmerged. +*/ +if (!vmg->give_up_on_oom) + vmg->state =VMA_MERGE_ERROR_NOMEM ;return NULL ; }
@@ -859,7 +865,15 @@ static struct vm_area_struct *vma_merge_ abort:vma_iter_set (vmg->vmi, start);vma_iter_load (vmg->vmi); - vmg->state =VMA_MERGE_ERROR_NOMEM ; + +/* +* This means we have failed to clone anon_vma's correctly, but no +* actual changes to VMAs have occurred, so no harm no foul - if the +* user doesn't want this reported and instead just wants to give up on +* the merge, allow it. +*/ +if (!vmg->give_up_on_oom) + vmg->state =VMA_MERGE_ERROR_NOMEM ;return NULL ; }
@@ -1033,9 +1047,15 @@ int vma_expand(struct vma_merge_struct *return 0 ; nomem: - vmg->state =VMA_MERGE_ERROR_NOMEM ;if (anon_dup)unlink_anon_vmas (anon_dup); +/* +* If the user requests that we just give upon OOM, we are safe to do so +* here, as commit merge provides this contract to us. Nothing has been +* changed - no harm no foul, just don't report it. +*/ +if (!vmg->give_up_on_oom) + vmg->state =VMA_MERGE_ERROR_NOMEM ;return -ENOMEM ; }
@@ -1428,6 +1448,13 @@ static struct vm_area_struct *vma_modifyif (vmg_nomem (vmg))return ERR_PTR (-ENOMEM ); +/* +* Split can fail for reasons other than OOM, so if the user requests +* this it's probably a mistake. +*/ +VM_WARN_ON (vmg->give_up_on_oom && + (vma->vm_start != start || vma->vm_end != end)); +/* Split any preceding portion of the VMA. */ if (vma->vm_start < start) {int err =split_vma (vmg->vmi, vma, start,1 );
@@ -1496,12 +1523,15 @@ struct vm_area_structstruct vm_area_struct *vma, unsigned long start, unsigned long end, unsigned long new_flags, - struct vm_userfaultfd_ctx new_ctx) + struct vm_userfaultfd_ctx new_ctx, + bool give_up_on_oom) {VMG_VMA_STATE (vmg ,vmi ,prev ,vma ,start ,end ); vmg.flags = new_flags; vmg.uffd_ctx = new_ctx; +if (give_up_on_oom) + vmg.give_up_on_oom = true;return vma_modify (&vmg); }
mm/vma.h +8 -1
@@ -87,6 +87,12 @@ struct vma_merge_struct {struct anon_vma_name *anon_name;enum vma_merge_flags merge_flags;enum vma_merge_state state; + +/* +* If a merge is possible, but an OOM error occurs, give up and don't +* execute the merge, returning NULL. +*/ + bool give_up_on_oom :1; };static inline bool vmg_nomem (struct vma_merge_struct *vmg)
@@ -303,7 +309,8 @@ struct vm_area_structstruct vm_area_struct *vma, unsigned long start, unsigned long end, unsigned long new_flags, - struct vm_userfaultfd_ctx new_ctx); + struct vm_userfaultfd_ctx new_ctx, + bool give_up_on_oom);struct vm_area_struct *vma_merge_new_range (struct vma_merge_struct *vmg);
Greg Kroah-Hartman
maintainerPATCH 210/223 Revert "wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process"
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Tsoy <[email protected]>
This reverts commit 535b666118f6ddeae90a480a146c061796d37022 which is commit 63fdc4509bcf483e79548de6bc08bf3c8e504bb3 upstream as it was backported incorrectly.
A subsequent commit will re-backport the original patch.
--- drivers/net/wireless/ath/ath12k/dp_mon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/ath/ath12k/dp_mon.c +1 -1
@@ -2533,7 +2533,7 @@ int ath12k_dp_mon_rx_process_stats(struc dest_idx =0 ; move_next:ath12k_dp_mon_buf_replenish (ab, buf_ring,1 ); -ath12k_hal_srng_dst_get_next_entry (ab, srng); +ath12k_hal_srng_src_get_next_entry (ab, srng); num_buffs_reaped++; }
Greg Kroah-Hartman
maintainerPATCH 211/223 MIPS: dec: Declare which_prom() as static
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: WangYuli <[email protected]>
commit 55fa5868519bc48a7344a4c070efa2f4468f2167 upstream.
Declare which_prom() as static to suppress gcc compiler warning that 'missing-prototypes'. This function is not intended to be called from other parts.
Fix follow error with gcc-14 when -Werror:
arch/mips/dec/prom/init.c:45:13: error: no previous prototype for ‘which_prom’ [-Werror=missing-prototypes]
45 | void __init which_prom(s32 magic, s32 *prom_vec)
| ^~~~~~~~~~
cc1: all warnings being treated as errors
make[6]: *** [scripts/Makefile.build:207: arch/mips/dec/prom/init.o] Error 1 make[5]: *** [scripts/Makefile.build:465: arch/mips/dec/prom] Error 2 make[5]: *** Waiting for unfinished jobs....
--- arch/mips/dec/prom/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/dec/prom/init.c +1 -1
@@ -42,7 +42,7 @@ int (*__pmax_close)(int);* Detect which PROM the DECSTATION has, and set the callback vectors * appropriately. */ -void __init which_prom (s32 magic,s32 *prom_vec) +static void __init which_prom (s32 magic,s32 *prom_vec) {/* * No sign of the REX PROM's magic number means we assume a non-REX
Greg Kroah-Hartman
maintainerPATCH 212/223 MIPS: cevt-ds1287: Add missing ds1287.h include
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: WangYuli <[email protected]>
commit f3be225f338a578851a7b607a409f476354a8deb upstream.
Address the issue of cevt-ds1287.c not including the ds1287.h header file.
Fix follow errors with gcc-14 when -Werror:
arch/mips/kernel/cevt-ds1287.c:15:5: error: no previous prototype for ‘ds1287_timer_state’ [-Werror=missing-prototypes]
15 | int ds1287_timer_state(void)
| ^~~~~~~~~~~~~~~~~~
arch/mips/kernel/cevt-ds1287.c:20:5: error: no previous prototype for ‘ds1287_set_base_clock’ [-Werror=missing-prototypes]
20 | int ds1287_set_base_clock(unsigned int hz)
| ^~~~~~~~~~~~~~~~~~~~~
arch/mips/kernel/cevt-ds1287.c:103:12: error: no previous prototype for ‘ds1287_clockevent_init’ [-Werror=missing-prototypes]
103 | int __init ds1287_clockevent_init(int irq)
| ^~~~~~~~~~~~~~~~~~~~~~cc1: all warnings being treated as errors
make[7]: *** [scripts/Makefile.build:207: arch/mips/kernel/cevt-ds1287.o] Error 1 make[7]: *** Waiting for unfinished jobs....
make[6]: *** [scripts/Makefile.build:465: arch/mips/kernel] Error 2 make[6]: *** Waiting for unfinished jobs....
--- arch/mips/kernel/cevt-ds1287.c | 1 + 1 file changed, 1 insertion(+)
arch/mips/kernel/cevt-ds1287.c +1 -0
@@ -10,6 +10,7 @@#include <linux/mc146818rtc.h> #include <linux/irq.h> +#include <asm/ds1287.h> #include <asm/time.h> int ds1287_timer_state (void )
Greg Kroah-Hartman
maintainerPATCH 213/223 MIPS: ds1287: Match ds1287_set_base_clock() function types
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: WangYuli <[email protected]>
commit a759109b234385b74d2f5f4c86b5f59b3201ec12 upstream.
Synchronize the declaration of ds1287_set_base_clock() between cevt-ds1287.c and ds1287.h.
Fix follow error with gcc-14 when -Werror:
arch/mips/kernel/cevt-ds1287.c:21:5: error: conflicting types for ‘ds1287_set_base_clock’; have ‘int(unsigned int)’
21 | int ds1287_set_base_clock(unsigned int hz)
| ^~~~~~~~~~~~~~~~~~~~~
In file included from arch/mips/kernel/cevt-ds1287.c:13:
./arch/mips/include/asm/ds1287.h:11:13: note: previous declaration of ‘ds1287_set_base_clock’ with type ‘void(unsigned int)’
11 | extern void ds1287_set_base_clock(unsigned int clock);
| ^~~~~~~~~~~~~~~~~~~~~make[7]: *** [scripts/Makefile.build:207: arch/mips/kernel/cevt-ds1287.o] Error 1 make[6]: *** [scripts/Makefile.build:465: arch/mips/kernel] Error 2 make[6]: *** Waiting for unfinished jobs....
--- arch/mips/include/asm/ds1287.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/mips/include/asm/ds1287.h +1 -1
@@ -8,7 +8,7 @@#define __ASM_DS1287_Hextern int ds1287_timer_state (void ); -extern void ds1287_set_base_clock (unsigned int clock); +extern int ds1287_set_base_clock (unsigned int hz);extern int ds1287_clockevent_init (int irq);#endif
Greg Kroah-Hartman
maintainerPATCH 214/223 wifi: ath12k: Fix invalid entry fetch in ath12k_dp_mon_srng_process
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: P Praneesh <[email protected]>
commit 63fdc4509bcf483e79548de6bc08bf3c8e504bb3 upstream.
Currently, ath12k_dp_mon_srng_process uses ath12k_hal_srng_src_get_next_entry to fetch the next entry from the destination ring. This is incorrect because ath12k_hal_srng_src_get_next_entry is intended for source rings, not destination rings. This leads to invalid entry fetches, causing potential data corruption or crashes due to accessing incorrect memory locations. This happens because the source ring and destination ring have different handling mechanisms and using the wrong function results in incorrect pointer arithmetic and ring management.
To fix this issue, replace the call to ath12k_hal_srng_src_get_next_entry with ath12k_hal_srng_dst_get_next_entry in ath12k_dp_mon_srng_process. This ensures that the correct function is used for fetching entries from the destination ring, preventing invalid memory accesses.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
--- drivers/net/wireless/ath/ath12k/dp_mon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/ath/ath12k/dp_mon.c +1 -1
@@ -2118,7 +2118,7 @@ int ath12k_dp_mon_srng_process(struct at dest_idx =0 ; move_next:ath12k_dp_mon_buf_replenish (ab, buf_ring,1 ); -ath12k_hal_srng_src_get_next_entry (ab, srng); +ath12k_hal_srng_dst_get_next_entry (ab, srng); num_buffs_reaped++; }
Greg Kroah-Hartman
maintainerPATCH 215/223 bpf: add find_containing_subprog() utility function
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eduard Zingerman <[email protected]>
commit 27e88bc4df1d80888fe1aaca786a7cc6e69587e2 upstream.
Add a utility function, looking for a subprogram containing a given instruction index, rewrite find_subprog() to use this function.
--- kernel/bpf/verifier.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-)
kernel/bpf/verifier.c +24 -4
@@ -2528,16 +2528,36 @@ static int cmp_subprogs(const void *a, c ((struct bpf_subprog_info *)b)->start; } +/* Find subprogram that contains instruction at 'off' */ +static struct bpf_subprog_info *find_containing_subprog (struct bpf_verifier_env *env,int off) +{ +struct bpf_subprog_info *vals = env->subprog_info; +int l, r, m; + +if (off >= env->prog->len || off <0 || env->subprog_cnt ==0 ) +return NULL ; + + l =0 ; + r = env->subprog_cnt -1 ; +while (l < r) { + m = l + (r - l +1 ) /2 ; +if (vals[m].start <= off) + l = m; +else + r = m -1 ; + } +return &vals[l]; +} + +/* Find subprogram that starts exactly at 'off' */ static int find_subprog (struct bpf_verifier_env *env,int off) {struct bpf_subprog_info *p; - p =bsearch (&off, env->subprog_info, env->subprog_cnt, -sizeof (env->subprog_info[0 ]), cmp_subprogs); -if (!p) + p =find_containing_subprog (env, off); +if (!p || p->start != off)return -ENOENT ;return p - env->subprog_info; - }static int add_subprog (struct bpf_verifier_env *env,int off)
Greg Kroah-Hartman
maintainerPATCH 216/223 bpf: track changes_pkt_data property for global functions
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eduard Zingerman <[email protected]>
commit 51081a3f25c742da5a659d7fc6fd77ebfdd555be upstream.
When processing calls to certain helpers, verifier invalidates all packet pointers in a current state. For example, consider the following program:
__attribute__((__noinline__))
long skb_pull_data(struct __sk_buff *sk, __u32 len)
{
return bpf_skb_pull_data(sk, len);
}
SEC("tc")
int test_invalidate_checks(struct __sk_buff *sk)
{
int *p = (void *)(long)sk->data;
if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP;
skb_pull_data(sk, 0);
*p = 42;
return TCX_PASS;
}After a call to bpf_skb_pull_data() the pointer 'p' can't be used safely. See function filter.c:bpf_helper_changes_pkt_data() for a list of such helpers.
At the moment verifier invalidates packet pointers when processing helper function calls, and does not traverse global sub-programs when processing calls to global sub-programs. This means that calls to helpers done from global sub-programs do not invalidate pointers in the caller state. E.g. the program above is unsafe, but is not rejected by verifier.
This commit fixes the omission by computing field bpf_subprog_info->changes_pkt_data for each sub-program before main verification pass.changes_pkt_data should be set if:
- subprogram calls helper for which bpf_helper_changes_pkt_data returns true;
- subprogram calls a global function,
for which bpf_subprog_info->changes_pkt_data should be set.
The verifier.c:check_cfg() pass is modified to compute this information. The commit relies on depth first instruction traversal done by check_cfg() and absence of recursive function calls:
- check_cfg() would eventually visit every call to subprogram S in a state when S is fully explored;
- when S is fully explored:
- every direct helper call within S is explored
(and thus changes_pkt_data is set if needed);
- every call to subprogram S1 called by S was visited with S1 fully explored (and thus S inherits changes_pkt_data from S1).
The downside of such approach is that dead code elimination is not taken into account: if a helper call inside global function is dead because of current configuration, verifier would conservatively assume that the call occurs for the purpose of the changes_pkt_data computation.
--- include/linux/bpf_verifier.h | 1 + kernel/bpf/verifier.c | 32 +++++++++++++++++++++++++++++++- 2 files changed, 32 insertions(+), 1 deletion(-)
include/linux/bpf_verifier.h +1 -0
@@ -668,6 +668,7 @@ struct bpf_subprog_info { bool args_cached: 1;/* true if bpf_fastcall stack region is used by functions that can't be inlined */ bool keep_fastcall_stack: 1; + bool changes_pkt_data: 1;u8 arg_cnt;struct bpf_subprog_arg_info args[MAX_BPF_FUNC_REG_ARGS ];
kernel/bpf/verifier.c +31 -1
@@ -9831,6 +9831,8 @@ static int check_func_call(struct bpf_veverbose (env,"Func#%d ('%s') is global and assumed valid.\n" , subprog, sub_name); +if (env->subprog_info[subprog].changes_pkt_data) +clear_all_pkt_pointers (env);/* mark global subprog for verifying after main prog */ subprog_aux (env, subprog)->called = true;clear_caller_saved_regs (env, caller->regs);
@@ -16021,6 +16023,29 @@ enforce_retval:return 0 ; } +static void mark_subprog_changes_pkt_data (struct bpf_verifier_env *env,int off) +{ +struct bpf_subprog_info *subprog; + + subprog =find_containing_subprog (env, off); + subprog->changes_pkt_data = true; +} + +/* 't' is an index of a call-site. +* 'w' is a callee entry point. +* Eventually this function would be called when env->cfg.insn_state[w] == EXPLORED. +* Rely on DFS traversal order and absence of recursive calls to guarantee that +* callee's change_pkt_data marks would be correct at that moment. +*/ +static void merge_callee_effects (struct bpf_verifier_env *env,int t,int w) +{ +struct bpf_subprog_info *caller, *callee; + + caller =find_containing_subprog (env, t); + callee =find_containing_subprog (env, w); + caller->changes_pkt_data |= callee->changes_pkt_data; +} +/* non-recursive DFS pseudo code * 1 procedure DFS-iterative(G,v): * 2 label v as discovered
@@ -16154,6 +16179,7 @@ static int visit_func_call_insn(int t, s bool visit_callee) {int ret, insn_sz; +int w; insn_sz =bpf_is_ldimm64 (&insns[t]) ?2 :1 ; ret =push_insn (t, t + insn_sz,FALLTHROUGH , env);
@@ -16165,8 +16191,10 @@ static int visit_func_call_insn(int t, smark_jmp_point (env, t + insn_sz);if (visit_callee) { + w = t + insns[t].imm +1 ;mark_prune_point (env, t); - ret =push_insn (t, t + insns[t].imm +1 ,BRANCH , env); +merge_callee_effects (env, t, w); + ret =push_insn (t, w,BRANCH , env); }return ret; }
@@ -16486,6 +16514,8 @@ static int visit_insn(int t, struct bpf_mark_prune_point (env, t);mark_jmp_point (env, t); } +if (bpf_helper_call (insn) &&bpf_helper_changes_pkt_data (insn->imm)) +mark_subprog_changes_pkt_data (env, t);if (insn->src_reg ==BPF_PSEUDO_KFUNC_CALL ) {struct bpf_kfunc_call_arg_meta meta;
Greg Kroah-Hartman
maintainerPATCH 217/223 selftests/bpf: test for changing packet data from global functions
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eduard Zingerman <[email protected]>
commit 3f23ee5590d9605dbde9a5e1d4b97637a4803329 upstream.
Check if verifier is aware of packet pointers invalidation done in global functions. Based on a test shared by Nick Zavaritsky in [0].
[0] https://lore.kernel.org/bpf/[email protected]/
--- tools/testing/selftests/bpf/progs/verifier_sock.c | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+)
tools/testing/selftests/bpf/progs/verifier_sock.c +28 -0
@@ -977,4 +977,32 @@ l1_%=: r0 = *(u8*)(r7 + 0); \ : __clobber_all); } +__noinline +long skb_pull_data2 (struct __sk_buff *sk,__u32 len) +{ +return bpf_skb_pull_data (sk, len); +} + +__noinline +long skb_pull_data1 (struct __sk_buff *sk,__u32 len) +{ +return skb_pull_data2 (sk, len); +} + +/* global function calls bpf_skb_pull_data(), which invalidates packet +* pointers established before global function call. +*/ +SEC("tc") +__failure __msg("invalid mem access") +int invalidate_pkt_pointers_from_global_func(struct __sk_buff *sk) +{ +int *p = (void *)(long )sk->data; + +if ((void *)(p +1 ) > (void *)(long )sk->data_end) +return TCX_DROP ; +skb_pull_data1 (sk,0 ); + *p =42 ;/* this is unsafe */ +return TCX_PASS ; +} + char _license[] SEC("license") = "GPL";
Greg Kroah-Hartman
maintainerPATCH 218/223 bpf: check changes_pkt_data property for extension programs
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eduard Zingerman <[email protected]>
commit 81f6d0530ba031b5f038a091619bf2ff29568852 upstream.
When processing calls to global sub-programs, verifier decides whether to invalidate all packet pointers in current state depending on the changes_pkt_data property of the global sub-program.
Because of this, an extension program replacing a global sub-program must be compatible with changes_pkt_data property of the sub-program being replaced.
This commit:
- adds changes_pkt_data flag to struct bpf_prog_aux:
- this flag is set in check_cfg() for main sub-program;
- in jit_subprogs() for other sub-programs;
- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;
- moves call to check_attach_btf_id() after the call to check_cfg(), because it needs changes_pkt_data flag to be set:
bpf_check:
... ...
- check_attach_btf_id resolve_pseudo_ldimm64
resolve_pseudo_ldimm64 --> bpf_prog_is_offloaded
bpf_prog_is_offloaded check_cfg
check_cfg + check_attach_btf_id
... ...
The following fields are set by check_attach_btf_id():
- env->ops
- prog->aux->attach_btf_trace
- prog->aux->attach_func_name
- prog->aux->attach_func_proto
- prog->aux->dst_trampoline
- prog->aux->mod
- prog->aux->saved_dst_attach_type
- prog->aux->saved_dst_prog_type
- prog->expected_attach_type
Neither of these fields are used by resolve_pseudo_ldimm64() or bpf_prog_offload_verifier_prep() (for netronome and netdevsim drivers), so the reordering is safe.
[ shung-hsi.yu: both jits_use_priv_stack and priv_stack_requested fields are missing from context because "bpf: Support private stack for bpf progs" series is not present.]
--- include/linux/bpf.h | 1 + kernel/bpf/verifier.c | 16 ++++++++++++---- 2 files changed, 13 insertions(+), 4 deletions(-)
include/linux/bpf.h +1 -0
@@ -1499,6 +1499,7 @@ struct bpf_prog_aux {bool exception_cb;bool exception_boundary;bool is_extended;/* true if extended by freplace program */ +bool changes_pkt_data;u64 prog_array_member_cnt;/* counts how many times as member of prog_array */ struct mutex ext_mutex;/* mutex for is_extended and prog_array_member_cnt */ struct bpf_arena *arena;
kernel/bpf/verifier.c +12 -4
@@ -16650,6 +16650,7 @@ walk_cfg: } } ret =0 ;/* cfg looks good */ + env->prog->aux->changes_pkt_data = env->subprog_info[0 ].changes_pkt_data; err_free:kvfree (insn_state);
@@ -20152,6 +20153,7 @@ static int jit_subprogs(struct bpf_verif func[i]->aux->num_exentries = num_exentries; func[i]->aux->tail_call_reachable = env->subprog_info[i].tail_call_reachable; func[i]->aux->exception_cb = env->subprog_info[i].is_exception_cb; + func[i]->aux->changes_pkt_data = env->subprog_info[i].changes_pkt_data;if (!i) func[i]->aux->exception_boundary = env->seen_exception; func[i] =bpf_int_jit_compile (func[i]);
@@ -22022,6 +22024,12 @@ int bpf_check_attach_target(struct bpf_v "Extension programs should be JITed\n");return -EINVAL ; } +if (prog->aux->changes_pkt_data && + !aux->func[subprog]->aux->changes_pkt_data) { +bpf_log (log, +"Extension program changes packet data, while original does not\n" ); +return -EINVAL ; + } }if (!tgt_prog->jited) {bpf_log (log,"Can attach to only JITed progs\n" );
@@ -22487,10 +22495,6 @@ int bpf_check(struct bpf_prog **prog, unif (ret <0 ) goto skip_full_check; - ret =check_attach_btf_id (env); -if (ret) - goto skip_full_check; - ret =resolve_pseudo_ldimm64 (env);if (ret <0 ) goto skip_full_check;
@@ -22505,6 +22509,10 @@ int bpf_check(struct bpf_prog **prog, unif (ret <0 ) goto skip_full_check; + ret =check_attach_btf_id (env); +if (ret) + goto skip_full_check; + ret =mark_fastcall_patterns (env);if (ret <0 ) goto skip_full_check;
Greg Kroah-Hartman
maintainerPATCH 219/223 selftests/bpf: freplace tests for tracking of changes_packet_data
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eduard Zingerman <[email protected]>
commit 89ff40890d8f12a7d7e93fb602cc27562f3834f0 upstream.
Try different combinations of global functions replacement:
- replace function that changes packet data with one that doesn't;
- replace function that changes packet data with one that does;
- replace function that doesn't change packet data with one that does;
- replace function that doesn't change packet data with one that doesn't;
--- tools/testing/selftests/bpf/prog_tests/changes_pkt_data.c | 76 ++++++++++ tools/testing/selftests/bpf/progs/changes_pkt_data.c | 26 +++ tools/testing/selftests/bpf/progs/changes_pkt_data_freplace.c | 18 ++ 3 files changed, 120 insertions(+) create mode 100644 tools/testing/selftests/bpf/prog_tests/changes_pkt_data.c create mode 100644 tools/testing/selftests/bpf/progs/changes_pkt_data.c create mode 100644 tools/testing/selftests/bpf/progs/changes_pkt_data_freplace.c
tools/testing/selftests/bpf/prog_tests/changes_pkt_data.c new file +76 -0
@@ -0,0 +1,76 @@ +// SPDX-License-Identifier: GPL-2.0 +#include "bpf/libbpf.h" +#include "changes_pkt_data_freplace.skel.h" +#include "changes_pkt_data.skel.h" +#include <test_progs.h> + +static void print_verifier_log (const char *log) +{ +if (env.verbosity >=VERBOSE_VERY ) +fprintf (stdout,"VERIFIER LOG:\n=============\n%s=============\n" , log); +} + +static void test_aux (const char *main_prog_name,const char *freplace_prog_name,bool expect_load) +{ +struct changes_pkt_data_freplace *freplace =NULL ; +struct bpf_program *freplace_prog =NULL ; +LIBBPF_OPTS (bpf_object_open_opts, opts); +struct changes_pkt_data *main =NULL ; +char log[16 *1024 ]; +int err; + + opts.kernel_log_buf = log; + opts.kernel_log_size =sizeof (log); +if (env.verbosity >=VERBOSE_SUPER ) + opts.kernel_log_level =1 |2 |4 ; + main =changes_pkt_data__open_opts (&opts); +if (!ASSERT_OK_PTR (main,"changes_pkt_data__open" )) + goto out; + err =changes_pkt_data__load (main); +print_verifier_log (log); +if (!ASSERT_OK (err,"changes_pkt_data__load" )) + goto out; + freplace =changes_pkt_data_freplace__open_opts (&opts); +if (!ASSERT_OK_PTR (freplace,"changes_pkt_data_freplace__open" )) + goto out; + freplace_prog =bpf_object__find_program_by_name (freplace->obj, freplace_prog_name); +if (!ASSERT_OK_PTR (freplace_prog,"freplace_prog" )) + goto out; +bpf_program__set_autoload (freplace_prog, true); +bpf_program__set_autoattach (freplace_prog, true); +bpf_program__set_attach_target (freplace_prog, +bpf_program__fd (main->progs.dummy), + main_prog_name); + err =changes_pkt_data_freplace__load (freplace); +print_verifier_log (log); +if (expect_load) { +ASSERT_OK (err,"changes_pkt_data_freplace__load" ); + }else { +ASSERT_ERR (err,"changes_pkt_data_freplace__load" ); +ASSERT_HAS_SUBSTR (log,"Extension program changes packet data" ,"error log" ); + } + +out: +changes_pkt_data_freplace__destroy (freplace); +changes_pkt_data__destroy (main); +} + +/* There are two global subprograms in both changes_pkt_data.skel.h: +* - one changes packet data; +* - another does not. +* It is ok to freplace subprograms that change packet data with those +* that either do or do not. It is only ok to freplace subprograms +* that do not change packet data with those that do not as well. +* The below tests check outcomes for each combination of such freplace. +*/ +void test_changes_pkt_data_freplace (void ) +{ +if (test__start_subtest ("changes_with_changes" )) +test_aux ("changes_pkt_data" ,"changes_pkt_data" , true); +if (test__start_subtest ("changes_with_doesnt_change" )) +test_aux ("changes_pkt_data" ,"does_not_change_pkt_data" , true); +if (test__start_subtest ("doesnt_change_with_changes" )) +test_aux ("does_not_change_pkt_data" ,"changes_pkt_data" , false); +if (test__start_subtest ("doesnt_change_with_doesnt_change" )) +test_aux ("does_not_change_pkt_data" ,"does_not_change_pkt_data" , true); +}
tools/testing/selftests/bpf/progs/changes_pkt_data.c new file +26 -0
@@ -0,0 +1,26 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <linux/bpf.h> +#include <bpf/bpf_helpers.h> + +__noinline +long changes_pkt_data (struct __sk_buff *sk,__u32 len) +{ +return bpf_skb_pull_data (sk, len); +} + +__noinline __weak +long does_not_change_pkt_data (struct __sk_buff *sk,__u32 len) +{ +return 0 ; +} + +SEC("tc") +int dummy (struct __sk_buff *sk) +{ +changes_pkt_data (sk,0 ); +does_not_change_pkt_data (sk,0 ); +return 0 ; +} + +char _license[] SEC("license") = "GPL";
tools/testing/selftests/bpf/progs/changes_pkt_data_freplace.c new file +18 -0
@@ -0,0 +1,18 @@ +// SPDX-License-Identifier: GPL-2.0 + +#include <linux/bpf.h> +#include <bpf/bpf_helpers.h> + +SEC("?freplace") +long changes_pkt_data (struct __sk_buff *sk,__u32 len) +{ +return bpf_skb_pull_data (sk, len); +} + +SEC("?freplace") +long does_not_change_pkt_data (struct __sk_buff *sk,__u32 len) +{ +return 0 ; +} + +char _license[] SEC("license") = "GPL";
Greg Kroah-Hartman
maintainerPATCH 220/223 selftests/bpf: validate that tail call invalidates packet pointers
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eduard Zingerman <[email protected]>
commit d9706b56e13b7916461ca6b4b731e169ed44ed09 upstream.
Add a test case with a tail call done from a global sub-program. Such tails calls should be considered as invalidating packet pointers.
--- tools/testing/selftests/bpf/progs/verifier_sock.c | 28 ++++++++++++++++++++++ 1 file changed, 28 insertions(+)
tools/testing/selftests/bpf/progs/verifier_sock.c +28 -0
@@ -50,6 +50,13 @@ struct {__uint (map_flags,BPF_F_NO_PREALLOC ); } sk_storage_map SEC(".maps"); +struct { + __uint(type, BPF_MAP_TYPE_PROG_ARRAY); + __uint(max_entries, 1); + __uint(key_size, sizeof(__u32)); + __uint(value_size, sizeof(__u32)); +} jmp_table SEC(".maps"); + SEC("cgroup/skb") __description("skb->sk: no NULL check") __failure __msg("invalid mem access 'sock_common_or_null'")
@@ -1004,5 +1011,26 @@ int invalidate_pkt_pointers_from_global_ *p =42 ;/* this is unsafe */ return TCX_PASS ; } + +__noinline +int tail_call(struct __sk_buff *sk) +{ +bpf_tail_call_static (sk, &jmp_table,0 ); +return 0 ; +} + +/* Tail calls invalidate packet pointers. */ +SEC("tc") +__failure __msg("invalid mem access") +int invalidate_pkt_pointers_by_tail_call(struct __sk_buff *sk) +{ +int *p = (void *)(long )sk->data; + +if ((void *)(p +1 ) > (void *)(long )sk->data_end) +return TCX_DROP ; +tail_call (sk); + *p =42 ;/* this is unsafe */ +return TCX_PASS ; +} char _license[] SEC("license") = "GPL";
Greg Kroah-Hartman
maintainerPATCH 221/223 bpf: fix null dereference when computing changes_pkt_data of prog w/o subprogs
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eduard Zingerman <[email protected]>
commit ac6542ad92759cda383ad62b4e4cbfc28136abc1 upstream.
bpf_prog_aux->func field might be NULL if program does not have subprograms except for main sub-program. The fixed commit does bpf_prog_aux->func access unconditionally, which might lead to null pointer dereference.
The bug could be triggered by replacing the following BPF program:
SEC("tc")
int main_changes(struct __sk_buff *sk)
{
bpf_skb_pull_data(sk, 0);
return 0;
}With the following BPF program:
SEC("freplace")
long changes_pkt_data(struct __sk_buff *sk)
{
return bpf_skb_pull_data(sk, 0);
}bpf_prog_aux instance itself represents the main sub-program, use this property to fix the bug.
--- kernel/bpf/verifier.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
kernel/bpf/verifier.c +5 -2
@@ -21990,6 +21990,7 @@ int bpf_check_attach_target(struct bpf_v }if (tgt_prog) {struct bpf_prog_aux *aux = tgt_prog->aux; +bool tgt_changes_pkt_data;if (bpf_prog_is_dev_bound (prog->aux) && !bpf_prog_dev_bound_match (prog, tgt_prog)) {
@@ -22024,8 +22025,10 @@ int bpf_check_attach_target(struct bpf_v "Extension programs should be JITed\n");return -EINVAL ; } -if (prog->aux->changes_pkt_data && - !aux->func[subprog]->aux->changes_pkt_data) { + tgt_changes_pkt_data = aux->func + ? aux->func[subprog]->aux->changes_pkt_data + : aux->changes_pkt_data; +if (prog->aux->changes_pkt_data && !tgt_changes_pkt_data) {bpf_log (log,"Extension program changes packet data, while original does not\n" );return -EINVAL ;
Greg Kroah-Hartman
maintainerPATCH 222/223 selftests/bpf: extend changes_pkt_data with cases w/o subprograms
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eduard Zingerman <[email protected]>
commit 04789af756a4a43e72986185f66f148e65b32fed upstream.
Extend changes_pkt_data tests with test cases freplacing the main program that does not have subprograms. Try four combinations when both main program and replacement do and do not change packet data.
--- tools/testing/selftests/bpf/prog_tests/changes_pkt_data.c | 55 +++++++--- tools/testing/selftests/bpf/progs/changes_pkt_data.c | 27 +++- tools/testing/selftests/bpf/progs/changes_pkt_data_freplace.c | 6 - 3 files changed, 66 insertions(+), 22 deletions(-)
tools/testing/selftests/bpf/prog_tests/changes_pkt_data.c +43 -12
@@ -10,10 +10,14 @@ static void print_verifier_log(const chafprintf (stdout,"VERIFIER LOG:\n=============\n%s=============\n" , log); } -static void test_aux (const char *main_prog_name,const char *freplace_prog_name,bool expect_load) +static void test_aux (const char *main_prog_name, +const char *to_be_replaced, +const char *replacement, +bool expect_load) {struct changes_pkt_data_freplace *freplace =NULL ;struct bpf_program *freplace_prog =NULL ; +struct bpf_program *main_prog =NULL ;LIBBPF_OPTS (bpf_object_open_opts, opts);struct changes_pkt_data *main =NULL ;char log[16 *1024 ];
@@ -26,6 +30,10 @@ static void test_aux(const char *main_pr main =changes_pkt_data__open_opts (&opts);if (!ASSERT_OK_PTR (main,"changes_pkt_data__open" )) goto out; + main_prog =bpf_object__find_program_by_name (main->obj, main_prog_name); +if (!ASSERT_OK_PTR (main_prog,"main_prog" )) + goto out; +bpf_program__set_autoload (main_prog, true); err =changes_pkt_data__load (main);print_verifier_log (log);if (!ASSERT_OK (err,"changes_pkt_data__load" ))
@@ -33,14 +41,14 @@ static void test_aux(const char *main_pr freplace =changes_pkt_data_freplace__open_opts (&opts);if (!ASSERT_OK_PTR (freplace,"changes_pkt_data_freplace__open" )) goto out; - freplace_prog =bpf_object__find_program_by_name (freplace->obj, freplace_prog_name); + freplace_prog =bpf_object__find_program_by_name (freplace->obj, replacement);if (!ASSERT_OK_PTR (freplace_prog,"freplace_prog" )) goto out;bpf_program__set_autoload (freplace_prog, true);bpf_program__set_autoattach (freplace_prog, true);bpf_program__set_attach_target (freplace_prog, -bpf_program__fd (main->progs.dummy), - main_prog_name); +bpf_program__fd (main_prog), + to_be_replaced); err =changes_pkt_data_freplace__load (freplace);print_verifier_log (log);if (expect_load) {
@@ -62,15 +70,38 @@ out:* that either do or do not. It is only ok to freplace subprograms * that do not change packet data with those that do not as well. * The below tests check outcomes for each combination of such freplace. +* Also test a case when main subprogram itself is replaced and is a single +* subprogram in a program. */ void test_changes_pkt_data_freplace (void ) { -if (test__start_subtest ("changes_with_changes" )) -test_aux ("changes_pkt_data" ,"changes_pkt_data" , true); -if (test__start_subtest ("changes_with_doesnt_change" )) -test_aux ("changes_pkt_data" ,"does_not_change_pkt_data" , true); -if (test__start_subtest ("doesnt_change_with_changes" )) -test_aux ("does_not_change_pkt_data" ,"changes_pkt_data" , false); -if (test__start_subtest ("doesnt_change_with_doesnt_change" )) -test_aux ("does_not_change_pkt_data" ,"does_not_change_pkt_data" , true); +struct { +const char *main; +const char *to_be_replaced; +bool changes; + } mains[] = { + {"main_with_subprogs" ,"changes_pkt_data" , true }, + {"main_with_subprogs" ,"does_not_change_pkt_data" , false }, + {"main_changes" ,"main_changes" , true }, + {"main_does_not_change" ,"main_does_not_change" , false }, + }; +struct { +const char *func; +bool changes; + } replacements[] = { + {"changes_pkt_data" , true }, + {"does_not_change_pkt_data" , false } + }; +char buf[64 ]; + +for (int i =0 ; i <ARRAY_SIZE (mains); ++i) { +for (int j =0 ; j <ARRAY_SIZE (replacements); ++j) { +snprintf (buf,sizeof (buf),"%s_with_%s" , + mains[i].to_be_replaced, replacements[j].func); +if (!test__start_subtest (buf)) +continue ; +test_aux (mains[i].main, mains[i].to_be_replaced, replacements[j].func, + mains[i].changes || !replacements[j].changes); + } + } }
tools/testing/selftests/bpf/progs/changes_pkt_data.c +20 -7
@@ -4,22 +4,35 @@#include <bpf/bpf_helpers.h> __noinline -long changes_pkt_data (struct __sk_buff *sk,__u32 len) +long changes_pkt_data (struct __sk_buff *sk) { -return bpf_skb_pull_data (sk, len); +return bpf_skb_pull_data (sk,0 ); }__noinline __weak -long does_not_change_pkt_data (struct __sk_buff *sk,__u32 len) +long does_not_change_pkt_data (struct __sk_buff *sk) {return 0 ; } -SEC("tc") -int dummy (struct __sk_buff *sk) +SEC("?tc") +int main_with_subprogs (struct __sk_buff *sk) +{ +changes_pkt_data (sk); +does_not_change_pkt_data (sk); +return 0 ; +} + +SEC("?tc") +int main_changes (struct __sk_buff *sk) +{ +bpf_skb_pull_data (sk,0 ); +return 0 ; +} + +SEC("?tc") +int main_does_not_change (struct __sk_buff *sk) { -changes_pkt_data (sk,0 ); -does_not_change_pkt_data (sk,0 );return 0 ; }
tools/testing/selftests/bpf/progs/changes_pkt_data_freplace.c +3 -3
@@ -4,13 +4,13 @@#include <bpf/bpf_helpers.h> SEC("?freplace") -long changes_pkt_data (struct __sk_buff *sk,__u32 len) +long changes_pkt_data (struct __sk_buff *sk) { -return bpf_skb_pull_data (sk, len); +return bpf_skb_pull_data (sk,0 ); } SEC("?freplace") -long does_not_change_pkt_data (struct __sk_buff *sk,__u32 len) +long does_not_change_pkt_data (struct __sk_buff *sk) {return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 223/223 block: make struct rq_list available for !CONFIG_BLOCK
In reply to Greg Kroah-Hartman6.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jens Axboe <[email protected]>
commit 957860cbc1dc89f79f2acc193470224e350dfd03 upstream.
A previous commit changed how requests are linked in the plug structure, but unlike the previous method, it uses a new type for it rather than struct request. The latter is available even for !CONFIG_BLOCK, while struct rq_list is now. Move it outside CONFIG_BLOCK.
--- include/linux/blkdev.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/blkdev.h +1 -1
@@ -995,12 +995,12 @@ extern void blk_put_queue(struct requestvoid blk_mark_disk_dead (struct gendisk *disk); -#ifdef CONFIG_BLOCK struct rq_list {struct request *head;struct request *tail; }; +#ifdef CONFIG_BLOCK /* * blk_plug permits building a queue of related requests by holding the I/O * fragments for a short period. This allows merging of sequential requests
Am 23.04.2025 um 16:41 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 25 Apr 2025 14:25:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.25-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 25 Apr 2025 14:25:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.25-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 25 Apr 2025 14:25:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.25-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 6.12.25-rc1
* git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
* git commit: 56d2398227a26c9827858b438ba125e54ae8b9f2
* git describe: v6.12.24-224-g56d2398227a2
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.12.y/build/v6.12.24-224-g56d2398227a2
## Test Regressions (compared to v6.12.23-393-g7b7562936f80)
## Metric Regressions (compared to v6.12.23-393-g7b7562936f80)
## Test Fixes (compared to v6.12.23-393-g7b7562936f80)
## Metric Fixes (compared to v6.12.23-393-g7b7562936f80)
## Test result summary
total: 126085, pass: 105995, fail: 3148, skip: 16539, xfail: 403
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 139 total, 137 passed, 2 failed
* arm64: 57 total, 57 passed, 0 failed
* i386: 18 total, 18 passed, 0 failed
* mips: 34 total, 33 passed, 1 failed
* parisc: 4 total, 4 passed, 0 failed
* powerpc: 40 total, 40 passed, 0 failed
* riscv: 25 total, 23 passed, 2 failed
* s390: 22 total, 21 passed, 1 failed
* sh: 5 total, 5 passed, 0 failed
* sparc: 4 total, 3 passed, 1 failed
* x86_64: 49 total, 49 passed, 0 failed
## Test suites summary
* boot
* commands
* kselftest-arm64
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-efivarfs
* kselftest-exec
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-kcmp
* kselftest-kvm
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-mincore
* kselftest-mqueue
* kselftest-net
* kselftest-net-mptcp
* kselftest-openat2
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user_events
* kselftest-vDSO
* kselftest-x86
* kunit
* kvm-unit-tests
* lava
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-build-clang
* log-parser-build-gcc
* log-parser-test
* ltp-capability
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-hugetlb
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-pty
* ltp-sched
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
* rt-tests-cyclicdeadline
* rt-tests-pi-stress
* rt-tests-pmqtest
* rt-tests-rt-migrate-test
* rt-tests-signaltest
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 25 Apr 2025 14:25:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.25-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.12:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
116 tests: 116 pass, 0 failLinux version: 6.12.25-rc1-g56d2398227a2
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 25 Apr 2025 14:25:27 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.25-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.12.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 25 Apr 2025 14:25:27 +0000. Anything received after that time might be too late.
Hi Greg
6.12.25-rc1 compiles, boots and runs here on x86_64 (AMD Ryzen 5 7520U, Slackware64-current).
I noticed that in 2 of 3 reboots X is slow to start (but is usable) and in dmesg I found this:
[Thu Apr 24 19:34:11 2025] amdgpu 0000:03:00.0: amdgpu: Dumping IP State [Thu Apr 24 19:34:11 2025] amdgpu 0000:03:00.0: amdgpu: Dumping IP State Completed [Thu Apr 24 19:34:11 2025] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=4, emitted seq=5 [Thu Apr 24 19:34:11 2025] amdgpu 0000:03:00.0: amdgpu: Process information: process Xorg pid 1733 thread Xorg:cs0 pid 1734 [Thu Apr 24 19:34:11 2025] amdgpu 0000:03:00.0: amdgpu: GPU reset begin! [Thu Apr 24 19:34:12 2025] amdgpu 0000:03:00.0: amdgpu: MODE2 reset [Thu Apr 24 19:34:12 2025] amdgpu 0000:03:00.0: amdgpu: GPU reset succeeded, trying to resume [Thu Apr 24 19:34:12 2025] amdgpu 0000:03:00.0: amdgpu: PSP is resuming... [Thu Apr 24 19:34:12 2025] amdgpu 0000:03:00.0: amdgpu: reserve 0xa00000 from 0xf41e000000 for PSP TMR [Thu Apr 24 19:34:12 2025] amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available [Thu Apr 24 19:34:12 2025] amdgpu 0000:03:00.0: amdgpu: RAP: optional rap ta ucode is not available [Thu Apr 24 19:34:12 2025] amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available [Thu Apr 24 19:34:12 2025] amdgpu 0000:03:00.0: amdgpu: SMU is resuming... [Thu Apr 24 19:34:12 2025] amdgpu 0000:03:00.0: amdgpu: SMU is resumed successfully! [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring gfx_0.1.0 uses VM inv eng 1 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 4 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 5 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring kiq_0.2.1.0 uses VM inv eng 12 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring sdma0 uses VM inv eng 13 on hub 0 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring vcn_dec_0 uses VM inv eng 0 on hub 8 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc_0.0 uses VM inv eng 1 on hub 8 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring vcn_enc_0.1 uses VM inv eng 4 on hub 8 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: ring jpeg_dec uses VM inv eng 5 on hub 8 [Thu Apr 24 19:34:13 2025] amdgpu 0000:03:00.0: amdgpu: GPU reset(2) succeeded! [Thu Apr 24 19:34:14 2025] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize parser -125!
Quoted 8 lines · On Wed, 23 Apr 2025 16:41:12 +0200 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 25 Apr 2025 14:25:27 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for loongarch64:
Thanks!
Cheers,
Miguel
Hi Greg,
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 25 Apr 2025 14:25:27 +0000. Anything received after that time might be too late.
...
Quoted 3 lines
Nathan Chancellor <[email protected]>
kbuild: Add '-fno-builtin-wcslen'
This patch was already in 6.12.24, and it is now twice in 6.12.y.
3802df8552de kbuild: Add '-fno-builtin-wcslen'9c03f6194e88 kbuild: Add '-fno-builtin-wcslen'
and
$ grep fno-builtin-wcslen Makefile KBUILD_CFLAGS += -fno-builtin-wcslen KBUILD_CFLAGS += -fno-builtin-wcslen
This is the second time this happened in the 6.12 series. The other sequence is
61749c035911 Revert "vfio/platform: check the bounds of read/write syscalls" 61ba518195d6 vfio/platform: check the bounds of read/write syscalls a20fcaa230f7 vfio/platform: check the bounds of read/write syscalls
Would it be possible to avoid those duplicates ? It doesn't matter in the above cases, but we might not always be that lucky.
Thanks,
Guenter
Greg Kroah-Hartman
maintainerQuoted 27 lines · Guenter Roeck
Hi Greg,
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.12.25 release. There are 223 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 25 Apr 2025 14:25:27 +0000. Anything received after that time might be too late.
...
Quoted 3 lines
Nathan Chancellor <[email protected]>
kbuild: Add '-fno-builtin-wcslen'This patch was already in 6.12.24, and it is now twice in 6.12.y.
3802df8552dekbuild: Add '-fno-builtin-wcslen'9c03f6194e88kbuild: Add '-fno-builtin-wcslen'and
$ grep fno-builtin-wcslen Makefile KBUILD_CFLAGS += -fno-builtin-wcslen KBUILD_CFLAGS += -fno-builtin-wcslen
Quoted 8 lines
This is the second time this happened in the 6.12 series. The other sequence is
61749c035911Revert "vfio/platform: check the bounds of read/write syscalls"61ba518195d6vfio/platform: check the bounds of read/write syscallsa20fcaa230f7vfio/platform: check the bounds of read/write syscallsWould it be possible to avoid those duplicates ? It doesn't matter in the above cases, but we might not always be that lucky.
Sorry about that, it's not a normal thing, and yes, our scripts should check it. I'll work on adding it in the future, thanks.
greg k-h