March 2024 - Linux-stable-mirror

[PATCH 6.6 00/24] xfs backports for 6.6.y (from 6.8)

by Catherine Hoang

Hello, This series contains backports for 6.6 from the 6.8 release. This patchset has gone through xfs testing and review. Andrey Albershteyn (1): xfs: reset XFS_ATTR_INCOMPLETE filter on node removal Christoph Hellwig (1): xfs: consider minlen sized extents in xfs_rtallocate_extent_block Darrick J. Wong (16): xfs: move the xfs_rtbitmap.c declarations to xfs_rtbitmap.h xfs: convert rt bitmap extent lengths to xfs_rtbxlen_t xfs: don't leak recovered attri intent items xfs: use xfs_defer_pending objects to recover intent items xfs: pass the xfs_defer_pending object to iop_recover xfs: transfer recovered intent item ownership in ->iop_recover xfs: make rextslog computation consistent with mkfs xfs: fix 32-bit truncation in xfs_compute_rextslog xfs: don't allow overly small or large realtime volumes xfs: make xchk_iget safer in the presence of corrupt inode btrees xfs: remove unused fields from struct xbtree_ifakeroot xfs: recompute growfsrtfree transaction reservation while growing rt volume xfs: fix an off-by-one error in xreap_agextent_binval xfs: force all buffers to be written during btree bulk load xfs: add missing nrext64 inode flag check to scrub xfs: remove conditional building of rt geometry validator functions Dave Chinner (1): xfs: initialise di_crc in xfs_log_dinode Eric Sandeen (1): xfs: short circuit xfs_growfs_data_private() if delta is zero Jiachen Zhang (1): xfs: ensure logflagsp is initialized in xfs_bmap_del_extent_real Long Li (2): xfs: add lock protection when remove perag from radix tree xfs: fix perag leak when growfs fails Zhang Tianci (1): xfs: update dir3 leaf block metadata after swap fs/xfs/libxfs/xfs_ag.c | 36 +++++++-- fs/xfs/libxfs/xfs_ag.h | 2 + fs/xfs/libxfs/xfs_attr.c | 6 +- fs/xfs/libxfs/xfs_bmap.c | 75 ++++++++----------- fs/xfs/libxfs/xfs_btree_staging.c | 4 +- fs/xfs/libxfs/xfs_btree_staging.h | 6 -- fs/xfs/libxfs/xfs_da_btree.c | 7 ++ fs/xfs/libxfs/xfs_defer.c | 105 +++++++++++++++++++------- fs/xfs/libxfs/xfs_defer.h | 5 ++ fs/xfs/libxfs/xfs_format.h | 2 +- fs/xfs/libxfs/xfs_log_recover.h | 5 ++ fs/xfs/libxfs/xfs_rtbitmap.c | 2 + fs/xfs/libxfs/xfs_rtbitmap.h | 83 +++++++++++++++++++++ fs/xfs/libxfs/xfs_sb.c | 20 ++++- fs/xfs/libxfs/xfs_sb.h | 2 + fs/xfs/libxfs/xfs_types.h | 13 ++++ fs/xfs/scrub/common.c | 6 +- fs/xfs/scrub/common.h | 25 +++++++ fs/xfs/scrub/fscounters.c | 2 +- fs/xfs/scrub/inode.c | 8 +- fs/xfs/scrub/reap.c | 2 +- fs/xfs/scrub/rtbitmap.c | 3 +- fs/xfs/scrub/rtsummary.c | 3 +- fs/xfs/scrub/trace.h | 3 +- fs/xfs/xfs_attr_item.c | 23 +++--- fs/xfs/xfs_bmap_item.c | 14 ++-- fs/xfs/xfs_buf.c | 44 ++++++++++- fs/xfs/xfs_buf.h | 1 + fs/xfs/xfs_extfree_item.c | 14 ++-- fs/xfs/xfs_fsmap.c | 2 +- fs/xfs/xfs_fsops.c | 9 ++- fs/xfs/xfs_inode_item.c | 3 + fs/xfs/xfs_log.c | 1 + fs/xfs/xfs_log_priv.h | 1 + fs/xfs/xfs_log_recover.c | 118 ++++++++++++++++-------------- fs/xfs/xfs_refcount_item.c | 13 ++-- fs/xfs/xfs_rmap_item.c | 14 ++-- fs/xfs/xfs_rtalloc.c | 14 +++- fs/xfs/xfs_rtalloc.h | 73 ------------------ fs/xfs/xfs_trans.h | 4 +- 40 files changed, 492 insertions(+), 281 deletions(-) create mode 100644 fs/xfs/libxfs/xfs_rtbitmap.h -- 2.39.3

11 months, 1 week

2
25
0 0

[PATCH 2/2] tracing: Remove unnecessary var destroy in onmax_destroy()

by George Guo

From: George Guo <guodongtai(a)kylinos.cn> The onmax_destroy() destroyed the onmax var, casusing a double-free error flagged by KASAN. This is tested via "./ftracetest test.d/trigger/inter-event/ trigger-onmatch-onmax-action-hist.tc". ================================================================== BUG: KASAN: use-after-free in destroy_hist_field+0x1c2/0x200 Read of size 8 at addr ffff88800a4ad100 by task ftracetest/4731 CPU: 0 PID: 4731 Comm: ftracetest Kdump: loaded Tainted: GE 4.19.90-89 #77 Source Version: Unknown Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0 Call Trace: dump_stack+0xcb/0x10b print_address_description.cold+0x54/0x249 kasan_report_error.cold+0x63/0xab ? destroy_hist_field+0x1c2/0x200 ? hist_trigger_elt_data_alloc+0x5a0/0x5a0 __asan_report_load8_noabort+0x8d/0xa0 ? destroy_hist_field+0x1c2/0x200 destroy_hist_field+0x1c2/0x200 onmax_destroy+0x72/0x1e0 ? hist_trigger_elt_data_alloc+0x5a0/0x5a0 destroy_hist_data+0x236/0xa40 event_hist_trigger_free+0x212/0x2f0 ? update_cond_flag+0x128/0x170 ? event_hist_trigger_func+0x2880/0x2880 hist_unregister_trigger+0x2f2/0x4f0 event_hist_trigger_func+0x168c/0x2880 ? tracing_map_cmp_u64+0xa0/0xa0 ? onmatch_create.constprop.0+0xf50/0xf50 ? __mutex_lock_slowpath+0x10/0x10 event_trigger_write+0x2f4/0x490 ? trigger_start+0x180/0x180 ? __fget_light+0x369/0x5d0 ? count_memcg_event_mm+0x104/0x2b0 ? trigger_start+0x180/0x180 __vfs_write+0x81/0x100 vfs_write+0x1e1/0x540 ksys_write+0x12a/0x290 ? __ia32_sys_read+0xb0/0xb0 ? __close_fd+0x1d3/0x280 do_syscall_64+0xe3/0x2d0 entry_SYSCALL_64_after_hwframe+0x5c/0xc1 RIP: 0033:0x7fd7f4c44e04 Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 39 34 0c 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 RSP: 002b:00007fff10370df8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000010f RCX: 00007fd7f4c44e04 RDX: 000000000000010f RSI: 000055fa765df650 RDI: 0000000000000001 RBP: 000055fa765df650 R08: 000000000000000a R09: 0000000000000000 R10: 000000000000000a R11: 0000000000000246 R12: 00007fd7f4d035c0 R13: 000000000000010f R14: 00007fd7f4d037c0 R15: 000000000000010f ================================================================== So remove the onmax_destroy() destroy_hist_field() call for that var. Fixes: 50450603ec9c("tracing: Add 'onmax' hist trigger action support") Cc: stable(a)vger.kernel.org Signed-off-by: George Guo <guodongtai(a)kylinos.cn> --- kernel/trace/trace_events_hist.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index 7dcb96305e56..58b8a2575b8c 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -337,7 +337,6 @@ struct action_data { char *fn_name; unsigned int max_var_ref_idx; struct hist_field *max_var; - struct hist_field *var; } onmax; }; }; @@ -3489,7 +3488,6 @@ static void onmax_destroy(struct action_data *data) unsigned int i; destroy_hist_field(data->onmax.max_var, 0); - destroy_hist_field(data->onmax.var, 0); kfree(data->onmax.var_str); kfree(data->onmax.fn_name); @@ -3528,8 +3526,6 @@ static int onmax_create(struct hist_trigger_data *hist_data, if (!ref_field) return -ENOMEM; - data->onmax.var = ref_field; - data->fn = onmax_save; data->onmax.max_var_ref_idx = var_ref_idx; max_var = create_var(hist_data, file, "max", sizeof(u64), "u64"); -- 2.34.1

11 months, 1 week

2
1
0 0

[PATCH 1/2] tracing: Remove unnecessary hist_data destroy in destroy_synth_var_refs()

by George Guo

From: George Guo <guodongtai(a)kylinos.cn> The destroy_synth_var_refs() destroyed hist_data, casusing a double-free error flagged by KASAN. This is tested via "./ftracetest test.d/trigger/inter-event/ trigger-field-variable-support.tc" ================================================================== BUG: KASAN: use-after-free in destroy_hist_field+0x115/0x140 Read of size 4 at addr ffff888012e95318 by task ftracetest/1858 CPU: 1 PID: 1858 Comm: ftracetest Kdump: loaded Tainted: GE 4.19.90-89 #24 Source Version: Unknown Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0 Call Trace: dump_stack+0xcb/0x10b print_address_description.cold+0x54/0x249 kasan_report_error.cold+0x63/0xab ? destroy_hist_field+0x115/0x140 __asan_report_load4_noabort+0x8d/0xa0 ? destroy_hist_field+0x115/0x140 destroy_hist_field+0x115/0x140 destroy_hist_data+0x4e4/0x9a0 event_hist_trigger_free+0x212/0x2f0 ? update_cond_flag+0x128/0x170 ? event_hist_trigger_func+0x2880/0x2880 hist_unregister_trigger+0x2f2/0x4f0 event_hist_trigger_func+0x168c/0x2880 ? tracing_map_read_var_once+0xd0/0xd0 ? create_key_field+0x520/0x520 ? __mutex_lock_slowpath+0x10/0x10 event_trigger_write+0x2f4/0x490 ? trigger_start+0x180/0x180 ? __fget_light+0x369/0x5d0 ? count_memcg_event_mm+0x104/0x2b0 ? trigger_start+0x180/0x180 __vfs_write+0x81/0x100 vfs_write+0x1e1/0x540 ksys_write+0x12a/0x290 ? __ia32_sys_read+0xb0/0xb0 ? __close_fd+0x1d3/0x280 do_syscall_64+0xe3/0x2d0 entry_SYSCALL_64_after_hwframe+0x5c/0xc1 RIP: 0033:0x7efdd342ee04 Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 39 34 0c 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5 RSP: 002b:00007ffda01f5e08 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00000000000000b4 RCX: 00007efdd342ee04 RDX: 00000000000000b4 RSI: 000055c5b41b1e90 RDI: 0000000000000001 RBP: 000055c5b41b1e90 R08: 000000000000000a R09: 0000000000000000 R10: 000000000000000a R11: 0000000000000246 R12: 00007efdd34ed5c0 R13: 00000000000000b4 R14: 00007efdd34ed7c0 R15: 00000000000000b4 ================================================================== So remove the destroy_synth_var_refs() call for that hist_data. Fixes: c282a386a397("tracing: Add 'onmatch' hist trigger action support") Cc: stable(a)vger.kernel.org Signed-off-by: George Guo <guodongtai(a)kylinos.cn> --- kernel/trace/trace_events_hist.c | 23 ++--------------------- 1 file changed, 2 insertions(+), 21 deletions(-) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index e004daf8cad5..7dcb96305e56 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -280,8 +280,6 @@ struct hist_trigger_data { struct action_data *actions[HIST_ACTIONS_MAX]; unsigned int n_actions; - struct hist_field *synth_var_refs[SYNTH_FIELDS_MAX]; - unsigned int n_synth_var_refs; struct field_var *field_vars[SYNTH_FIELDS_MAX]; unsigned int n_field_vars; unsigned int n_field_var_str; @@ -1363,8 +1361,8 @@ static struct hist_field *find_var_ref(struct hist_trigger_data *hist_data, return found; } - for (i = 0; i < hist_data->n_synth_var_refs; i++) { - hist_field = hist_data->synth_var_refs[i]; + for (i = 0; i < hist_data->n_var_refs; i++) { + hist_field = hist_data->var_refs[i]; found = check_field_for_var_refs(hist_data, hist_field, var_data, var_idx, 0); if (found) @@ -3707,21 +3705,6 @@ static void save_field_var(struct hist_trigger_data *hist_data, hist_data->n_field_var_str++; } - -static void destroy_synth_var_refs(struct hist_trigger_data *hist_data) -{ - unsigned int i; - - for (i = 0; i < hist_data->n_synth_var_refs; i++) - destroy_hist_field(hist_data->synth_var_refs[i], 0); -} - -static void save_synth_var_ref(struct hist_trigger_data *hist_data, - struct hist_field *var_ref) -{ - hist_data->synth_var_refs[hist_data->n_synth_var_refs++] = var_ref; -} - static int check_synth_field(struct synth_event *event, struct hist_field *hist_field, unsigned int field_pos) @@ -3884,7 +3867,6 @@ static int onmatch_create(struct hist_trigger_data *hist_data, goto err; } - save_synth_var_ref(hist_data, var_ref); field_pos++; kfree(p); continue; @@ -4631,7 +4613,6 @@ static void destroy_hist_data(struct hist_trigger_data *hist_data) destroy_actions(hist_data); destroy_field_vars(hist_data); destroy_field_var_hists(hist_data); - destroy_synth_var_refs(hist_data); kfree(hist_data); } -- 2.34.1

11 months, 1 week

2
1
0 0

Re: [PATCH stable 5.10] serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO

by Gong Ruiqi

Oops. + Cc stable(a)vger.kernel.org On 2024/03/18 10:52, GONG, Ruiqi wrote: > From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> > > commit dbf4ab821804df071c8b566d9813083125e6d97b upstream. > > The SC16IS7XX IC supports a burst mode to access the FIFOs where the > initial register address is sent ($00), followed by all the FIFO data > without having to resend the register address each time. In this mode, the > IC doesn't increment the register address for each R/W byte. > > The regmap_raw_read() and regmap_raw_write() are functions which can > perform IO over multiple registers. They are currently used to read/write > from/to the FIFO, and although they operate correctly in this burst mode on > the SPI bus, they would corrupt the regmap cache if it was not disabled > manually. The reason is that when the R/W size is more than 1 byte, these > functions assume that the register address is incremented and handle the > cache accordingly. > > Convert FIFO R/W functions to use the regmap _noinc_ versions in order to > remove the manual cache control which was a workaround when using the > _raw_ versions. FIFO registers are properly declared as volatile so > cache will not be used/updated for FIFO accesses. > > Fixes: dfeae619d781 ("serial: sc16is7xx") > Cc: <stable(a)vger.kernel.org> > Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> > Link: https://lore.kernel.org/r/20231211171353.2901416-6-hugo@hugovil.com > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Cc: Hugo Villeneuve <hvilleneuve(a)dimonoff.com> > Signed-off-by: GONG, Ruiqi <gongruiqi1(a)huawei.com> > --- > > The mainline commit dbf4ab821804 ("serial: sc16is7xx: convert from _raw_ > to _noinc_ regmap functions for FIFO") by Hugo has been assigned to be > CVE-2023-52488, but for stable branches lower than 6.1 there's no > official backport. > > I made up this backport patch for 5.10, and its correctness has been > confirmed in previous communication with Hugo. Let's publicize it and > merge it into upstream. > > drivers/tty/serial/sc16is7xx.c | 15 +++++++++------ > 1 file changed, 9 insertions(+), 6 deletions(-) > > diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c > index 31e0c5c3ddea..29f05db0d49b 100644 > --- a/drivers/tty/serial/sc16is7xx.c > +++ b/drivers/tty/serial/sc16is7xx.c > @@ -376,9 +376,7 @@ static void sc16is7xx_fifo_read(struct uart_port *port, unsigned int rxlen) > const u8 line = sc16is7xx_line(port); > u8 addr = (SC16IS7XX_RHR_REG << SC16IS7XX_REG_SHIFT) | line; > > - regcache_cache_bypass(s->regmap, true); > - regmap_raw_read(s->regmap, addr, s->buf, rxlen); > - regcache_cache_bypass(s->regmap, false); > + regmap_noinc_read(s->regmap, addr, s->buf, rxlen); > } > > static void sc16is7xx_fifo_write(struct uart_port *port, u8 to_send) > @@ -394,9 +392,7 @@ static void sc16is7xx_fifo_write(struct uart_port *port, u8 to_send) > if (unlikely(!to_send)) > return; > > - regcache_cache_bypass(s->regmap, true); > - regmap_raw_write(s->regmap, addr, s->buf, to_send); > - regcache_cache_bypass(s->regmap, false); > + regmap_noinc_write(s->regmap, addr, s->buf, to_send); > } > > static void sc16is7xx_port_update(struct uart_port *port, u8 reg, > @@ -489,6 +485,11 @@ static bool sc16is7xx_regmap_precious(struct device *dev, unsigned int reg) > return false; > } > > +static bool sc16is7xx_regmap_noinc(struct device *dev, unsigned int reg) > +{ > + return reg == SC16IS7XX_RHR_REG; > +} > + > static int sc16is7xx_set_baud(struct uart_port *port, int baud) > { > struct sc16is7xx_port *s = dev_get_drvdata(port->dev); > @@ -1439,6 +1440,8 @@ static struct regmap_config regcfg = { > .cache_type = REGCACHE_RBTREE, > .volatile_reg = sc16is7xx_regmap_volatile, > .precious_reg = sc16is7xx_regmap_precious, > + .writeable_noinc_reg = sc16is7xx_regmap_noinc, > + .readable_noinc_reg = sc16is7xx_regmap_noinc, > }; > > #ifdef CONFIG_SERIAL_SC16IS7XX_SPI

11 months, 1 week

2
1
0 0

[PATCH] wifi: rtw88: 8821cu: Fix connection failure

by Bitterblue Smith

From: Bitterblue Smith <rtl8821cerfe2(a)gmail.com> [ Upstream commit 605d7c0b05eecb985273b1647070497142c470d3 ] Clear bit 8 of REG_SYS_STATUS1 after MAC power on. Without this, some RTL8821CU and RTL8811CU cannot connect to any network: Feb 19 13:33:11 ideapad2 kernel: wlp3s0f3u2: send auth to 90:55:de:__:__:__ (try 1/3) Feb 19 13:33:13 ideapad2 kernel: wlp3s0f3u2: send auth to 90:55:de:__:__:__ (try 2/3) Feb 19 13:33:14 ideapad2 kernel: wlp3s0f3u2: send auth to 90:55:de:__:__:__ (try 3/3) Feb 19 13:33:15 ideapad2 kernel: wlp3s0f3u2: authentication with 90:55:de:__:__:__ timed out The RTL8822CU and RTL8822BU out-of-tree drivers do this as well, so do it for all three types of chips. Tested with RTL8811CU (Tenda U9 V2.0). Signed-off-by: Bitterblue Smith <rtl8821cerfe2(a)gmail.com> Acked-by: Ping-Ke Shih <pkshih(a)realtek.com> Signed-off-by: Kalle Valo <kvalo(a)kernel.org> Link: https://msgid.link/aeeefad9-27c8-4506-a510-ef9a9a8731a4@gmail.com --- drivers/net/wireless/realtek/rtw88/mac.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw88/mac.c b/drivers/net/wireless/realtek/rtw88/mac.c index 298663b03580..0c1c1ff31085 100644 --- a/drivers/net/wireless/realtek/rtw88/mac.c +++ b/drivers/net/wireless/realtek/rtw88/mac.c @@ -309,6 +309,13 @@ static int rtw_mac_power_switch(struct rtw_dev *rtwdev, bool pwr_on) pwr_seq = pwr_on ? chip->pwr_on_seq : chip->pwr_off_seq; ret = rtw_pwr_seq_parser(rtwdev, pwr_seq); + if (pwr_on && rtw_hci_type(rtwdev) == RTW_HCI_TYPE_USB) { + if (chip->id == RTW_CHIP_TYPE_8822C || + chip->id == RTW_CHIP_TYPE_8822B || + chip->id == RTW_CHIP_TYPE_8821C) + rtw_write8_clr(rtwdev, REG_SYS_STATUS1 + 1, BIT(0)); + } + if (rtw_hci_type(rtwdev) == RTW_HCI_TYPE_SDIO) rtw_write32(rtwdev, REG_SDIO_HIMR, imr); -- 2.43.2

11 months, 1 week

2
3
0 0

[PATCHi 6.6 0/1] Cherrypick one more commit to fix iwlwifi crash on BE200

by Aaron Ma

Hi Levin, On Stable 6.6.23 kernel, iwlwifi crashed with the following error: [ 290.279712] ------------[ cut here ]------------ [ 290.279726] Invalid rxb from HW 0 [ 290.279816] WARNING: CPU: 19 PID: 477 at drivers/net/wireless/intel/iwlwifi/pcie/rx.c:1489 iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.279885] Modules linked in: snd_ctl_led snd_soc_skl_hda_dsp snd_soc_intel_hda_dsp_common snd_soc_hdac_hdmi snd_sof_probes snd_hda_codec_realtek snd_hda_codec_generic rfcomm nvme_fabrics ccm cmac algif_hash algif_skcipher af_alg bnep uvcvideo videobuf2_vmalloc uvc videobuf2_memops videobuf2_v4l2 videodev btusb btrtl btintel btbcm btmtk videobuf2_common bluetooth mc ecdh_generic ecc joydev snd_soc_dmic intel_uncore_frequency intel_uncore_frequency_common snd_sof_pci_intel_mtl snd_sof_intel_hda_common x86_pkg_temp_thermal soundwire_intel intel_powerclamp soundwire_generic_allocation snd_sof_intel_hda_mlink soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp coretemp snd_sof snd_sof_utils snd_soc_hdac_hda snd_hda_ext_core kvm_intel snd_soc_acpi_intel_match snd_soc_acpi soundwire_bus kvm snd_soc_core irqbypass snd_compress crct10dif_pclmul ac97_bus crc32_pclmul snd_pcm_dmaengine polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 iwlmvm snd_hda_intel sha256_ssse3 binfmt_misc sha1_ssse3 i915 [ 290.279973] snd_intel_dspcfg drm_buddy aesni_intel snd_intel_sdw_acpi ttm mac80211 crypto_simd processor_thermal_device_pci snd_hda_codec drm_display_helper spi_nor hid_multitouch processor_thermal_device cryptd think_lmi pmt_telemetry hid_generic libarc4 mtd intel_rapl_msr pmt_class iwlwifi firmware_attributes_class wmi_bmof snd_hda_core cec processor_thermal_rfim rapl snd_hwdep psmouse thinkpad_acpi input_leds rc_core mei_me snd_seq_midi ucsi_acpi processor_thermal_mbox intel_cstate intel_lpss_pci snd_seq_midi_event typec_ucsi processor_thermal_rapl nvram i2c_i801 intel_lpss xhci_pci drm_kms_helper spi_intel_pci ledtrig_audio cfg80211 snd_pcm e1000e thunderbolt serio_raw platform_profile mei i2c_smbus spi_intel typec idma64 xhci_pci_renesas i2c_algo_bit intel_vsec intel_rapl_common snd_rawmidi mac_hid snd_seq snd_seq_device snd_timer i2c_hid_acpi i2c_hid hid snd soundcore video int3403_thermal int340x_thermal_zone wmi acpi_tad acpi_pad intel_pmc_core intel_hid int3400_thermal pinctrl_meteorlake sparse_keymap [ 290.280076] acpi_thermal_rel sch_fq_codel msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables autofs4 [ 290.280097] CPU: 19 PID: 477 Comm: irq/182-iwlwifi Not tainted 6.6.23 #75 [ 290.280104] Hardware name: LENOVO 21ML0SIT12/21ML0SIT12, BIOS N47ET13W (1.02 ) 02/17/2024 [ 290.280108] RIP: 0010:iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280156] Code: 8b 8d 6c ff ff ff 4c 89 f2 4c 89 e6 4c 89 ef e8 4a f4 ff ff e9 08 fe ff ff 4d 89 ef 89 d6 48 c7 c7 c5 6c bf c0 e8 44 1d 36 fb <0f> 0b 4c 89 ff e8 1a 48 ff ff e9 9e fe ff ff 0f 1f 44 00 00 e9 f6 [ 290.280161] RSP: 0018:ffffc900004e0de8 EFLAGS: 00010246 [ 290.280167] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 290.280170] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 290.280173] RBP: ffffc900004e0e98 R08: 0000000000000000 R09: 0000000000000000 [ 290.280176] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88811dd27f88 [ 290.280179] R13: ffff888119ae8028 R14: ffff88812c4a0000 R15: ffff888119ae8028 [ 290.280182] FS: 0000000000000000(0000) GS:ffff8882214c0000(0000) knlGS:0000000000000000 [ 290.280187] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 290.280191] CR2: 00007f914800ba8c CR3: 000000020e83a005 CR4: 0000000000770ee0 [ 290.280195] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 290.280198] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 290.280201] PKRU: 55555554 [ 290.280204] Call Trace: [ 290.280208] <IRQ> [ 290.280214] ? show_regs+0x72/0x90 [ 290.280225] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280269] ? __warn+0x8d/0x160 [ 290.280278] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280324] ? report_bug+0x1bb/0x1d0 [ 290.280335] ? console_unlock+0x77/0x130 [ 290.280346] ? handle_bug+0x46/0x90 [ 290.280354] ? exc_invalid_op+0x19/0x80 [ 290.280360] ? asm_exc_invalid_op+0x1b/0x20 [ 290.280369] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280412] ? iwl_pcie_rx_handle+0x80c/0xad0 [iwlwifi] [ 290.280457] iwl_pcie_napi_poll_msix+0x30/0x100 [iwlwifi] [ 290.280500] ? try_to_wake_up+0x278/0x6c0 [ 290.280507] __napi_poll+0x30/0x1f0 [ 290.280515] net_rx_action+0x190/0x300 [ 290.280521] ? __irq_wake_thread+0x42/0x50 [ 290.280529] __do_softirq+0xda/0x330 [ 290.280533] ? handle_edge_irq+0xda/0x250 [ 290.280540] ? __pfx_irq_thread_fn+0x10/0x10 [ 290.280547] do_softirq.part.0+0x41/0x80 [ 290.280557] </IRQ> [ 290.280559] <TASK> [ 290.280562] __local_bh_enable_ip+0x72/0x80 [ 290.280570] iwl_pcie_irq_rx_msix_handler+0xd7/0x1c0 [iwlwifi] [ 290.280644] irq_thread_fn+0x25/0x70 [ 290.280653] irq_thread+0xea/0x1c0 [ 290.280660] ? __pfx_irq_thread_dtor+0x10/0x10 [ 290.280668] ? __pfx_irq_thread+0x10/0x10 [ 290.280675] kthread+0xf4/0x130 [ 290.280683] ? __pfx_kthread+0x10/0x10 [ 290.280690] ret_from_fork+0x43/0x70 [ 290.280697] ? __pfx_kthread+0x10/0x10 [ 290.280704] ret_from_fork_asm+0x1b/0x30 [ 290.280712] </TASK> [ 290.280715] ---[ end trace 0000000000000000 ]--- [ 290.281118] iwlwifi 0000:09:00.0: Microcode SW error detected. Restarting 0x0. Found the first bad commit c1c1039135c3 ("wifi: iwlwifi: increase number of RX buffers for EHT devices") Another commit should be along with it: commit 9f9797c7de18 ("wifi: iwlwifi: pcie: fix RB status reading") BugLink: https://bugs.launchpad.net/bugs/2058808 Johannes Berg (1): wifi: iwlwifi: pcie: fix RB status reading drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 8 ++++---- drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +- drivers/net/wireless/intel/iwlwifi/pcie/trans.c | 12 ++++-------- 3 files changed, 9 insertions(+), 13 deletions(-) -- 2.34.1

11 months, 1 week

2
2
0 0

Pull ASoC amd fixes into stable

by Luca Stefani

Hey stable folks, Can the following patches found in mainline [PATCH] ASoC: amd: yc: Revert "Fix non-functional mic on Lenovo 21J2" (861b341) [PATCH] ASoC: amd: yc: Revert "add new YC platform variant (0x63) support" (37bee18) be backported to linux-6.8.y? They're improperly assuming the 0x63 variant is part of the Yellow Carp family. This causes the microphone input device to not being properly probed on the device. Known broken devices: ThinkPad P16s Gen 2 (21K9CTO1WW) Thanks, Luca.

11 months, 1 week

2
1
0 0

Re: [PATCH 0/2] Revert "ASoC: amd: yc: add new YC platform variant (0x63) support"

by Luca Stefani

Hello everyone, Can those changes be pulled in stable? They're currently breaking mic input on my 21K9CTO1WW, ThinkPad P16s Gen 2, and probably more devices in the wild. Thanks, Luca. On 12/03/24 03:33, Jiawei Wang wrote: > Please revert my previous two commits: > > ASoC: amd: yc: add new YC platform variant (0x63) support > [ Upstream commit 316a784839b21b122e1761cdca54677bb19a47fa ] > > ASoC: amd: yc: Fix non-functional mic on Lenovo 21J2 > [ Upstream commit ed00a6945dc32462c2d3744a3518d2316da66fcc ] > > PCI revision id 0x63 is the Pink Sardine (PS) platform, not Yellow > Carp (YC). Thanks to Mukunda Vijendar [1] for pointing out that. > > The mic on Lenovo 21J2 works after enabling the CONFIG_SND_SOC_AMD_PS > flag, which I had not enabled when I was writing these patches. 21J2 > does not need to be in this quirk table. > > I apologize for the inconvenience caused. > > Link: https://lore.kernel.org/linux-sound/023092e1-689c-4b00-b93f-4092c3724fb6@am… [1] > > Signed-off-by: Jiawei Wang <me(a)jwang.link> > > Jiawei Wang (2): > Revert "ASoC: amd: yc: Fix non-functional mic on Lenovo 21J2" > Revert "ASoC: amd: yc: add new YC platform variant (0x63) support" > > sound/soc/amd/yc/acp6x-mach.c | 7 ------- > sound/soc/amd/yc/pci-acp6x.c | 1 - > 2 files changed, 8 deletions(-) >

11 months, 1 week

3
5
0 0

FAILED: Patch "x86/efistub: Call mixed mode boot services on the firmware's stack" failed to apply to 6.8-stable tree

by Sasha Levin

The patch below does not apply to the 6.8-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. Thanks, Sasha ------------------ original commit in Linus's tree ------------------ From cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ardb(a)kernel.org> Date: Fri, 22 Mar 2024 17:03:58 +0200 Subject: [PATCH] x86/efistub: Call mixed mode boot services on the firmware's stack Normally, the EFI stub calls into the EFI boot services using the stack that was live when the stub was entered. According to the UEFI spec, this stack needs to be at least 128k in size - this might seem large but all asynchronous processing and event handling in EFI runs from the same stack and so quite a lot of space may be used in practice. In mixed mode, the situation is a bit different: the bootloader calls the 32-bit EFI stub entry point, which calls the decompressor's 32-bit entry point, where the boot stack is set up, using a fixed allocation of 16k. This stack is still in use when the EFI stub is started in 64-bit mode, and so all calls back into the EFI firmware will be using the decompressor's limited boot stack. Due to the placement of the boot stack right after the boot heap, any stack overruns have gone unnoticed. However, commit 5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code") moved the definition of the boot heap into C code, and now the boot stack is placed right at the base of BSS, where any overruns will corrupt the end of the .data section. While it would be possible to work around this by increasing the size of the boot stack, doing so would affect all x86 systems, and mixed mode systems are a tiny (and shrinking) fraction of the x86 installed base. So instead, record the firmware stack pointer value when entering from the 32-bit firmware, and switch to this stack every time a EFI boot service call is made. Cc: <stable(a)kernel.org> # v6.1+ Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org> --- arch/x86/boot/compressed/efi_mixed.S | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/x86/boot/compressed/efi_mixed.S b/arch/x86/boot/compressed/efi_mixed.S index f4e22ef774ab6..719e939050cbf 100644 --- a/arch/x86/boot/compressed/efi_mixed.S +++ b/arch/x86/boot/compressed/efi_mixed.S @@ -49,6 +49,11 @@ SYM_FUNC_START(startup_64_mixed_mode) lea efi32_boot_args(%rip), %rdx mov 0(%rdx), %edi mov 4(%rdx), %esi + + /* Switch to the firmware's stack */ + movl efi32_boot_sp(%rip), %esp + andl $~7, %esp + #ifdef CONFIG_EFI_HANDOVER_PROTOCOL mov 8(%rdx), %edx // saved bootparams pointer test %edx, %edx @@ -254,6 +259,9 @@ SYM_FUNC_START_LOCAL(efi32_entry) /* Store firmware IDT descriptor */ sidtl (efi32_boot_idt - 1b)(%ebx) + /* Store firmware stack pointer */ + movl %esp, (efi32_boot_sp - 1b)(%ebx) + /* Store boot arguments */ leal (efi32_boot_args - 1b)(%ebx), %ebx movl %ecx, 0(%ebx) @@ -318,5 +326,6 @@ SYM_DATA_END(efi32_boot_idt) SYM_DATA_LOCAL(efi32_boot_cs, .word 0) SYM_DATA_LOCAL(efi32_boot_ds, .word 0) +SYM_DATA_LOCAL(efi32_boot_sp, .long 0) SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0, 0) SYM_DATA(efi_is64, .byte 1) -- 2.43.0

11 months, 1 week

3
5
0 0

[PATCH] tools/resolve_btfids: fix build with musl libc

by Natanael Copa

Include the header that defines u32. Fixes: 9707ac4fe2f5 ("tools/resolve_btfids: Refactor set sorting with types from btf_ids.h") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218647 Cc: stable(a)vger.kernel.org Signed-off-by: Natanael Copa <ncopa(a)alpinelinux.org> --- This fixes build of 6.6.23 and 6.1.83 kernels for Alpine Linux, which uses musl libc. I assume that GNU libc indirecly pulls in linux/types.h. tools/include/linux/btf_ids.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/include/linux/btf_ids.h b/tools/include/linux/btf_ids.h index 72535f00572f..72ea363d434d 100644 --- a/tools/include/linux/btf_ids.h +++ b/tools/include/linux/btf_ids.h @@ -3,6 +3,8 @@ #ifndef _LINUX_BTF_IDS_H #define _LINUX_BTF_IDS_H +#include <linux/types.h> /* for u32 */ + struct btf_id_set { u32 cnt; u32 ids[]; -- 2.44.0

11 months, 1 week

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2024