August 2024 - Linux-stable-mirror

[PATCH] wifi: mt76: mt7921: Check devm_kasprintf() returned value

by Ma Ke

devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 6ae39b7c7ed4 ("wifi: mt76: mt7921: Support temp sensor") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/net/wireless/mediatek/mt76/mt7921/init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/init.c b/drivers/net/wireless/mediatek/mt76/mt7921/init.c index ef0c721d26e3..5ab395d9d93e 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7921/init.c +++ b/drivers/net/wireless/mediatek/mt76/mt7921/init.c @@ -52,6 +52,8 @@ static int mt7921_thermal_init(struct mt792x_phy *phy) name = devm_kasprintf(&wiphy->dev, GFP_KERNEL, "mt7921_%s", wiphy_name(wiphy)); + if (!name) + return -ENOMEM; hwmon = devm_hwmon_device_register_with_groups(&wiphy->dev, name, phy, mt7921_hwmon_groups); -- 2.25.1

3 weeks, 4 days

1
0
0 0

[PATCH] bus: mhi: host: pci_generic: Fix the name for the Telit FE990A

by Fabio Porcedda

Add a mhi_pci_dev_info struct specific for the Telit FE990A modem in order to use the correct product name. Cc: stable(a)vger.kernel.org # 6.1+ Fixes: 0724869ede9c ("bus: mhi: host: pci_generic: add support for Telit FE990 modem") Signed-off-by: Fabio Porcedda <fabio.porcedda(a)gmail.com> --- drivers/bus/mhi/host/pci_generic.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c index 14a11880bcea..fb701c67f763 100644 --- a/drivers/bus/mhi/host/pci_generic.c +++ b/drivers/bus/mhi/host/pci_generic.c @@ -680,6 +680,15 @@ static const struct mhi_pci_dev_info mhi_telit_fn990_info = { .mru_default = 32768, }; +static const struct mhi_pci_dev_info mhi_telit_fe990a_info = { + .name = "telit-fe990a", + .config = &modem_telit_fn990_config, + .bar_num = MHI_PCI_DEFAULT_BAR_NUM, + .dma_data_width = 32, + .sideband_wake = false, + .mru_default = 32768, +}; + /* Keep the list sorted based on the PID. New VID should be added as the last entry */ static const struct pci_device_id mhi_pci_id_table[] = { { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0304), @@ -697,9 +706,9 @@ static const struct pci_device_id mhi_pci_id_table[] = { /* Telit FN990 */ { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0308, 0x1c5d, 0x2010), .driver_data = (kernel_ulong_t) &mhi_telit_fn990_info }, - /* Telit FE990 */ + /* Telit FE990A */ { PCI_DEVICE_SUB(PCI_VENDOR_ID_QCOM, 0x0308, 0x1c5d, 0x2015), - .driver_data = (kernel_ulong_t) &mhi_telit_fn990_info }, + .driver_data = (kernel_ulong_t) &mhi_telit_fe990a_info }, { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0308), .driver_data = (kernel_ulong_t) &mhi_qcom_sdx65_info }, { PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x0309), -- 2.46.0

3 weeks, 4 days

2
2
0 0

[PATCH v3 7/9] vdpa: solidrun: Fix UB bug with devres

by Philipp Stanner

In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf(). Cc: stable(a)vger.kernel.org # v6.3 Fixes: 51a8f9d7f587 ("virtio: vdpa: new SolidNET DPU driver.") Reported-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Closes: https://lore.kernel.org/all/74e9109a-ac59-49e2-9b1d-d825c9c9f891@wanadoo.fr/ Suggested-by: Andy Shevchenko <andy(a)kernel.org> Signed-off-by: Philipp Stanner <pstanner(a)redhat.com> --- drivers/vdpa/solidrun/snet_main.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/vdpa/solidrun/snet_main.c b/drivers/vdpa/solidrun/snet_main.c index 99428a04068d..67235f6190ef 100644 --- a/drivers/vdpa/solidrun/snet_main.c +++ b/drivers/vdpa/solidrun/snet_main.c @@ -555,7 +555,7 @@ static const struct vdpa_config_ops snet_config_ops = { static int psnet_open_pf_bar(struct pci_dev *pdev, struct psnet *psnet) { - char name[50]; + char *name; int ret, i, mask = 0; /* We don't know which BAR will be used to communicate.. * We will map every bar with len > 0. @@ -573,7 +573,10 @@ static int psnet_open_pf_bar(struct pci_dev *pdev, struct psnet *psnet) return -ENODEV; } - snprintf(name, sizeof(name), "psnet[%s]-bars", pci_name(pdev)); + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "psnet[%s]-bars", pci_name(pdev)); + if (!name) + return -ENOMEM; + ret = pcim_iomap_regions(pdev, mask, name); if (ret) { SNET_ERR(pdev, "Failed to request and map PCI BARs\n"); @@ -590,10 +593,12 @@ static int psnet_open_pf_bar(struct pci_dev *pdev, struct psnet *psnet) static int snet_open_vf_bar(struct pci_dev *pdev, struct snet *snet) { - char name[50]; + char *name; int ret; - snprintf(name, sizeof(name), "snet[%s]-bar", pci_name(pdev)); + name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "psnet[%s]-bars", pci_name(pdev)); + if (!name) + return -ENOMEM; /* Request and map BAR */ ret = pcim_iomap_regions(pdev, BIT(snet->psnet->cfg.vf_bar), name); if (ret) { -- 2.46.0

3 weeks, 4 days

3
3
0 0

[PATCH RESEND] wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he

by Ma Ke

Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (802.11be) devices") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c index 2e4fa9f48dfb..cba28d8d5562 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c @@ -1544,6 +1544,9 @@ mt7996_mcu_sta_bfer_he(struct ieee80211_sta *sta, struct ieee80211_vif *vif, u8 nss_mcs = mt7996_mcu_get_sta_nss(mcs_map); u8 snd_dim, sts; + if (!vc) + return; + bf->tx_mode = MT_PHY_TYPE_HE_SU; mt7996_mcu_sta_sounding_rate(bf); -- 2.25.1

3 weeks, 4 days

1
0
0 0

[PATCH 6.11 regression fix] ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards harder

by Hans de Goede

Since commit 13f58267cda3 ("ASoC: soc.h: don't create dummy Component via COMP_DUMMY()") dummy codecs declared like this: SND_SOC_DAILINK_DEF(dummy, DAILINK_COMP_ARRAY(COMP_DUMMY())); expand to: static struct snd_soc_dai_link_component dummy[] = { }; Which means that dummy is a zero sized array and thus dais[i].codecs should not be dereferenced *at all* since it points to the address of the next variable stored in the data section as the "dummy" variable has an address but no size, so even dereferencing dais[0] is already an out of bounds array reference. Which means that the if (dais[i].codecs->name) check added in commit 7d99a70b6595 ("ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards") relies on that the part of the next variable which the name member maps to just happens to be NULL. Which apparently so far it usually is, except when it isn't and then it results in crashes like this one: [ 28.795659] BUG: unable to handle page fault for address: 0000000000030011 ... [ 28.795780] Call Trace: [ 28.795787] <TASK> ... [ 28.795862] ? strcmp+0x18/0x40 [ 28.795872] 0xffffffffc150c605 [ 28.795887] platform_probe+0x40/0xa0 ... [ 28.795979] ? __pfx_init_module+0x10/0x10 [snd_soc_sst_bytcr_wm5102] Really fix things this time around by checking dais.num_codecs != 0. Fixes: 7d99a70b6595 ("ASoC: Intel: Boards: Fix NULL pointer deref in BYT/CHT boards") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- sound/soc/intel/boards/bxt_rt298.c | 2 +- sound/soc/intel/boards/bytcht_cx2072x.c | 2 +- sound/soc/intel/boards/bytcht_da7213.c | 2 +- sound/soc/intel/boards/bytcht_es8316.c | 2 +- sound/soc/intel/boards/bytcr_rt5640.c | 2 +- sound/soc/intel/boards/bytcr_rt5651.c | 2 +- sound/soc/intel/boards/bytcr_wm5102.c | 2 +- sound/soc/intel/boards/cht_bsw_rt5645.c | 2 +- sound/soc/intel/boards/cht_bsw_rt5672.c | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/sound/soc/intel/boards/bxt_rt298.c b/sound/soc/intel/boards/bxt_rt298.c index dce6a2086f2a..6da1517c53c6 100644 --- a/sound/soc/intel/boards/bxt_rt298.c +++ b/sound/soc/intel/boards/bxt_rt298.c @@ -605,7 +605,7 @@ static int broxton_audio_probe(struct platform_device *pdev) int i; for (i = 0; i < ARRAY_SIZE(broxton_rt298_dais); i++) { - if (card->dai_link[i].codecs->name && + if (card->dai_link[i].num_codecs && !strncmp(card->dai_link[i].codecs->name, "i2c-INT343A:00", I2C_NAME_SIZE)) { if (!strncmp(card->name, "broxton-rt298", diff --git a/sound/soc/intel/boards/bytcht_cx2072x.c b/sound/soc/intel/boards/bytcht_cx2072x.c index c014d85a08b2..df3c2a7b64d2 100644 --- a/sound/soc/intel/boards/bytcht_cx2072x.c +++ b/sound/soc/intel/boards/bytcht_cx2072x.c @@ -241,7 +241,7 @@ static int snd_byt_cht_cx2072x_probe(struct platform_device *pdev) /* fix index of codec dai */ for (i = 0; i < ARRAY_SIZE(byt_cht_cx2072x_dais); i++) { - if (byt_cht_cx2072x_dais[i].codecs->name && + if (byt_cht_cx2072x_dais[i].num_codecs && !strcmp(byt_cht_cx2072x_dais[i].codecs->name, "i2c-14F10720:00")) { dai_index = i; diff --git a/sound/soc/intel/boards/bytcht_da7213.c b/sound/soc/intel/boards/bytcht_da7213.c index f4ac3ddd148b..08c598b7e1ee 100644 --- a/sound/soc/intel/boards/bytcht_da7213.c +++ b/sound/soc/intel/boards/bytcht_da7213.c @@ -245,7 +245,7 @@ static int bytcht_da7213_probe(struct platform_device *pdev) /* fix index of codec dai */ for (i = 0; i < ARRAY_SIZE(dailink); i++) { - if (dailink[i].codecs->name && + if (dailink[i].num_codecs && !strcmp(dailink[i].codecs->name, "i2c-DLGS7213:00")) { dai_index = i; break; diff --git a/sound/soc/intel/boards/bytcht_es8316.c b/sound/soc/intel/boards/bytcht_es8316.c index 2fcec2e02bb5..77b91ea4dc32 100644 --- a/sound/soc/intel/boards/bytcht_es8316.c +++ b/sound/soc/intel/boards/bytcht_es8316.c @@ -546,7 +546,7 @@ static int snd_byt_cht_es8316_mc_probe(struct platform_device *pdev) /* fix index of codec dai */ for (i = 0; i < ARRAY_SIZE(byt_cht_es8316_dais); i++) { - if (byt_cht_es8316_dais[i].codecs->name && + if (byt_cht_es8316_dais[i].num_codecs && !strcmp(byt_cht_es8316_dais[i].codecs->name, "i2c-ESSX8316:00")) { dai_index = i; diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c index a64d1989e28a..db4a33680d94 100644 --- a/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5640.c @@ -1677,7 +1677,7 @@ static int snd_byt_rt5640_mc_probe(struct platform_device *pdev) /* fix index of codec dai */ for (i = 0; i < ARRAY_SIZE(byt_rt5640_dais); i++) { - if (byt_rt5640_dais[i].codecs->name && + if (byt_rt5640_dais[i].num_codecs && !strcmp(byt_rt5640_dais[i].codecs->name, "i2c-10EC5640:00")) { dai_index = i; diff --git a/sound/soc/intel/boards/bytcr_rt5651.c b/sound/soc/intel/boards/bytcr_rt5651.c index 80c841b000a3..8514b79f389b 100644 --- a/sound/soc/intel/boards/bytcr_rt5651.c +++ b/sound/soc/intel/boards/bytcr_rt5651.c @@ -910,7 +910,7 @@ static int snd_byt_rt5651_mc_probe(struct platform_device *pdev) /* fix index of codec dai */ for (i = 0; i < ARRAY_SIZE(byt_rt5651_dais); i++) { - if (byt_rt5651_dais[i].codecs->name && + if (byt_rt5651_dais[i].num_codecs && !strcmp(byt_rt5651_dais[i].codecs->name, "i2c-10EC5651:00")) { dai_index = i; diff --git a/sound/soc/intel/boards/bytcr_wm5102.c b/sound/soc/intel/boards/bytcr_wm5102.c index cccb5e90c0fe..e5a7cc606aa9 100644 --- a/sound/soc/intel/boards/bytcr_wm5102.c +++ b/sound/soc/intel/boards/bytcr_wm5102.c @@ -605,7 +605,7 @@ static int snd_byt_wm5102_mc_probe(struct platform_device *pdev) /* find index of codec dai */ for (i = 0; i < ARRAY_SIZE(byt_wm5102_dais); i++) { - if (byt_wm5102_dais[i].codecs->name && + if (byt_wm5102_dais[i].num_codecs && !strcmp(byt_wm5102_dais[i].codecs->name, "wm5102-codec")) { dai_index = i; diff --git a/sound/soc/intel/boards/cht_bsw_rt5645.c b/sound/soc/intel/boards/cht_bsw_rt5645.c index eb41b7115d01..1da9ceee4d59 100644 --- a/sound/soc/intel/boards/cht_bsw_rt5645.c +++ b/sound/soc/intel/boards/cht_bsw_rt5645.c @@ -569,7 +569,7 @@ static int snd_cht_mc_probe(struct platform_device *pdev) /* set correct codec name */ for (i = 0; i < ARRAY_SIZE(cht_dailink); i++) - if (cht_dailink[i].codecs->name && + if (cht_dailink[i].num_codecs && !strcmp(cht_dailink[i].codecs->name, "i2c-10EC5645:00")) { dai_index = i; diff --git a/sound/soc/intel/boards/cht_bsw_rt5672.c b/sound/soc/intel/boards/cht_bsw_rt5672.c index be2d1a8dbca8..d68e5bc755de 100644 --- a/sound/soc/intel/boards/cht_bsw_rt5672.c +++ b/sound/soc/intel/boards/cht_bsw_rt5672.c @@ -466,7 +466,7 @@ static int snd_cht_mc_probe(struct platform_device *pdev) /* find index of codec dai */ for (i = 0; i < ARRAY_SIZE(cht_dailink); i++) { - if (cht_dailink[i].codecs->name && + if (cht_dailink[i].num_codecs && !strcmp(cht_dailink[i].codecs->name, RT5672_I2C_DEFAULT)) { dai_index = i; break; -- 2.46.0

3 weeks, 4 days

4
4
0 0

[PATCH v1 1/2] ufs: core: complete scsi command after release

by peter.wang＠mediatek.com

From: Peter Wang <peter.wang(a)mediatek.com> When the error handler successfully aborts a MCQ request, it only releases the command and does not notify the SCSI layer. This may cause another abort after 30 seconds timeout. This patch notifies the SCSI layer to requeue the request. Below is error log [ 14.183804][ T74] ufshcd-mtk 112b0000.ufshci: ufshcd_err_handler started; HBA state eh_non_fatal; powered 1; shutting down 0; saved_err = 4; saved_uic_err = 64; force_reset = 0 [ 14.256164][ T74] ufshcd-mtk 112b0000.ufshci: ufshcd_try_to_abort_task: cmd pending in the device. tag = 19 [ 14.257511][ T74] ufshcd-mtk 112b0000.ufshci: Aborting tag 19 / CDB 0x35 succeeded [ 34.287949][ T8] ufshcd-mtk 112b0000.ufshci: ufshcd_abort: Device abort task at tag 19 [ 34.290514][ T8] ufshcd-mtk 112b0000.ufshci: ufshcd_mcq_abort: skip abort. cmd at tag 19 already completed. Fixes:93e6c0e19d5b ("scsi: ufs: core: Clear cmd if abort succeeds in MCQ mode") Cc: <stable(a)vger.kernel.org> 6.6.x Signed-off-by: Peter Wang <peter.wang(a)mediatek.com> --- drivers/ufs/core/ufshcd.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index 0b3d0c8e0dda..4bcd4e5b62bd 100644 --- a/drivers/ufs/core/ufshcd.c +++ b/drivers/ufs/core/ufshcd.c @@ -6482,8 +6482,12 @@ static bool ufshcd_abort_one(struct request *rq, void *priv) if (!hwq) return 0; spin_lock_irqsave(&hwq->cq_lock, flags); - if (ufshcd_cmd_inflight(lrbp->cmd)) + if (ufshcd_cmd_inflight(lrbp->cmd)) { + struct scsi_cmnd *cmd = lrbp->cmd; + set_host_byte(cmd, DID_REQUEUE); ufshcd_release_scsi_cmd(hba, lrbp); + scsi_done(cmd); + } spin_unlock_irqrestore(&hwq->cq_lock, flags); } -- 2.45.2

3 weeks, 4 days

3
2
0 0

Re: [tip: perf/core] perf/core: Fix hardlockup failure caused by perf throttle

by Pengfei Xu

Hi Jihong and perf experts, Greetings! There was "BUG: soft lockup in asm_sysvec_apic_timer_interrupt" in v6.11-rc4 mainline kernel by local syzkaller Intel internal kernel testing. Bisected and found first bad commit: " 15def34e2635 perf/core: Fix hardlockup failure caused by perf throttle " After reverted above commit on top of v6.11-rc4 mainline kernel, this issue was gone. And this issue could be reproduced in 1200s. All detailed info: https://github.com/xupengfe/syzkaller_logs/tree/main/240823_212601_asm_sysv… Syzkaller repro code: https://github.com/xupengfe/syzkaller_logs/blob/main/240823_212601_asm_sysv… Syzkaller repro syscall steps: https://github.com/xupengfe/syzkaller_logs/blob/main/240823_212601_asm_sysv… Syzkaller report: https://github.com/xupengfe/syzkaller_logs/blob/main/240823_212601_asm_sysv… Kconfig(make olddefconfig): https://github.com/xupengfe/syzkaller_logs/blob/main/240823_212601_asm_sysv… Bisect info: https://github.com/xupengfe/syzkaller_logs/blob/main/240823_212601_asm_sysv… bzImage: https://github.com/xupengfe/syzkaller_logs/raw/main/240823_212601_asm_sysve… Issue dmesg: https://github.com/xupengfe/syzkaller_logs/blob/main/240823_212601_asm_sysv… " [ 22.518698] hrtimer: interrupt took 13103 ns [ 30.382700] clocksource: Long readout interval, skipping watchdog check: cs_nsec: 2079936720 wd_nsec: 2079936828 [ 378.038693] clocksource: Long readout interval, skipping watchdog check: cs_nsec: 7719948786 wd_nsec: 7719948793 [ 736.508865] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:193160] [ 736.509218] Modules linked in: [ 736.509369] irq event stamp: 15405229 [ 736.509539] hardirqs last enabled at (15405228): [<ffffffff8579c9de>] irqentry_exit+0x3e/0xa0 [ 736.509947] hardirqs last disabled at (15405229): [<ffffffff8579ae14>] sysvec_apic_timer_interrupt+0x14/0xc0 [ 736.510383] softirqs last enabled at (9218742): [<ffffffff81289fb9>] __irq_exit_rcu+0xa9/0x120 [ 736.510776] softirqs last disabled at (9218745): [<ffffffff81289fb9>] __irq_exit_rcu+0xa9/0x120 [ 736.511167] CPU: 0 UID: 0 PID: 193160 Comm: repro Not tainted 6.11.0-rc4-47ac09b91bef+ #1 [ 736.511529] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 736.512039] RIP: 0010:__rcu_read_unlock+0x284/0x560 [ 736.512272] Code: 8f 00 00 00 84 d2 0f 84 87 00 00 00 bf 09 00 00 00 e8 d0 0b dc ff 4d 85 f6 0f 84 68 fe ff ff e8 f2 83 26 00 fb 0f 1f 44 00 00 <e9> 58 fe ff ff 0f 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 [ 736.513091] RSP: 0018:ffff88806c609938 EFLAGS: 00000212 [ 736.513330] RAX: 0000000000e956e0 RBX: ffff88806c649600 RCX: 1ffffffff14ae71b [ 736.513648] RDX: 0000000000000000 RSI: 0000000000000101 RDI: 0000000000000000 [ 736.513974] RBP: ffff88806c609968 R08: 0000000000000001 R09: fffffbfff14a92b5 [ 736.514289] R10: ffffffff8a5495af R11: 0000000000000001 R12: ffff88801379ca00 [ 736.514606] R13: ffff88801379ca00 R14: 0000000000000200 R15: ffffffff86e619c0 [ 736.514935] FS: 00007f095e148740(0000) GS:ffff88806c600000(0000) knlGS:0000000000000000 [ 736.515293] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 736.515555] CR2: 0000000020000000 CR3: 0000000021944006 CR4: 0000000000770ef0 [ 736.515888] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 736.516215] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 [ 736.516539] PKRU: 55555554 [ 736.516672] Call Trace: [ 736.516798] <IRQ> [ 736.516907] ? show_regs+0xa8/0xc0 [ 736.517080] ? watchdog_timer_fn+0x52f/0x6b0 [ 736.517284] ? __pfx_watchdog_timer_fn+0x10/0x10 [ 736.517503] ? __hrtimer_run_queues+0x5d6/0xb10 [ 736.517733] ? __pfx___hrtimer_run_queues+0x10/0x10 [ 736.517975] ? hrtimer_interrupt+0x324/0x7a0 [ 736.518193] ? __sysvec_apic_timer_interrupt+0x10b/0x410 [ 736.518443] ? debug_smp_processor_id+0x20/0x30 [ 736.518663] ? sysvec_apic_timer_interrupt+0x4b/0xc0 [ 736.518901] ? asm_sysvec_apic_timer_interrupt+0x1f/0x30 [ 736.519162] ? __rcu_read_unlock+0x284/0x560 [ 736.519370] ? __rcu_read_unlock+0x27e/0x560 [ 736.519579] __is_insn_slot_addr+0x14c/0x2a0 [ 736.519791] kernel_text_address+0x64/0xe0 [ 736.519991] __kernel_text_address+0x16/0x50 [ 736.520199] unwind_get_return_address+0x8c/0x100 [ 736.520424] ? __pfx_stack_trace_consume_entry+0x10/0x10 [ 736.520671] arch_stack_walk+0xa7/0x170 [ 736.520878] stack_trace_save+0x97/0xd0 [ 736.521064] ? __pfx_stack_trace_save+0x10/0x10 [ 736.521276] ? __pfx_mark_lock.part.0+0x10/0x10 [ 736.521499] kasan_save_stack+0x2c/0x60 [ 736.521681] ? kasan_save_stack+0x2c/0x60 [ 736.521870] ? kasan_save_track+0x18/0x40 [ 736.522057] ? kasan_save_free_info+0x3f/0x60 [ 736.522267] ? __kasan_slab_free+0x115/0x1a0 [ 736.522467] ? kfree+0xfe/0x330 [ 736.522622] ? free_ctx+0x22/0x30 [ 736.522788] ? rcu_core+0x877/0x18f0 [ 736.522967] ? rcu_core_si+0x12/0x20 [ 736.523142] ? handle_softirqs+0x1c7/0x870 [ 736.523334] ? __irq_exit_rcu+0xa9/0x120 [ 736.523519] ? irq_exit_rcu+0x12/0x30 [ 736.523693] ? sysvec_apic_timer_interrupt+0xa5/0xc0 [ 736.523922] ? asm_sysvec_apic_timer_interrupt+0x1f/0x30 [ 736.524165] ? lock_acquire+0x1ff/0x580 [ 736.524352] ? _raw_spin_lock+0x38/0x50 [ 736.524534] ? do_fcntl+0xa95/0x1400 [ 736.524709] ? __x64_sys_fcntl+0x179/0x210 [ 736.524906] ? x64_sys_call+0x5b9/0x20d0 [ 736.525094] ? do_syscall_64+0x6d/0x140 [ 736.525276] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 736.525529] ? __pfx___lock_acquire+0x10/0x10 [ 736.525736] ? do_raw_spin_trylock+0xbf/0x190 [ 736.525949] ? free_unref_page_commit+0x3c0/0xfb0 [ 736.526176] ? __this_cpu_preempt_check+0x21/0x30 [ 736.526399] ? lock_acquire+0x1de/0x580 [ 736.526587] ? free_ctx+0x22/0x30 [ 736.526753] kasan_save_track+0x18/0x40 [ 736.526944] kasan_save_free_info+0x3f/0x60 [ 736.527146] __kasan_slab_free+0x115/0x1a0 [ 736.527341] ? free_ctx+0x22/0x30 [ 736.527503] kfree+0xfe/0x330 [ 736.527655] ? rcu_core+0x875/0x18f0 [ 736.527833] free_ctx+0x22/0x30 [ 736.527991] rcu_core+0x877/0x18f0 [ 736.528165] ? __pfx_rcu_core+0x10/0x10 [ 736.528365] rcu_core_si+0x12/0x20 [ 736.528535] handle_softirqs+0x1c7/0x870 [ 736.528734] __irq_exit_rcu+0xa9/0x120 [ 736.528915] irq_exit_rcu+0x12/0x30 [ 736.529085] sysvec_apic_timer_interrupt+0xa5/0xc0 [ 736.529309] </IRQ> [ 736.529414] <TASK> [ 736.529522] asm_sysvec_apic_timer_interrupt+0x1f/0x30 [ 736.529762] RIP: 0010:lock_acquire+0x1ff/0x580 [ 736.529974] Code: 48 83 c4 28 e8 72 73 37 04 b8 ff ff ff ff 65 0f c1 05 fd b6 c0 7e 83 f8 01 0f 85 d9 02 00 00 4d 85 ff 74 06 fb 0f 1f 44 00 00 <48> b8 00 00 00 00 00 fc ff df 48 01 c3 48 c7 03 00 00 00 00 48 c7 [ 736.530786] RSP: 0018:ffff88801aa0fcd0 EFLAGS: 00000206 [ 736.531031] RAX: 0000000000000001 RBX: 1ffff11003541f9e RCX: 1ffff11003541f82 [ 736.531348] RDX: 1ffff110026f3b07 RSI: 0000000000000001 RDI: 0000000000000000 [ 736.531668] RBP: ffff88801aa0fdb8 R08: 0000000000000000 R09: fffffbfff14a92b5 [ 736.531994] R10: ffffffff8a5495af R11: 0000000000000001 R12: 0000000000000001 [ 736.532318] R13: 0000000000000000 R14: ffff88800f65a028 R15: 0000000000000200 [ 736.532660] ? __pfx_lock_acquire+0x10/0x10 [ 736.532860] ? _raw_spin_unlock+0x31/0x60 [ 736.533063] ? up_write+0x1c0/0x550 [ 736.533234] ? fasync_helper+0x77/0xc0 [ 736.533420] _raw_spin_lock+0x38/0x50 [ 736.533595] ? do_fcntl+0xa95/0x1400 [ 736.533775] do_fcntl+0xa95/0x1400 [ 736.533948] ? __pfx_do_fcntl+0x10/0x10 [ 736.534137] ? trace_hardirqs_on+0x51/0x60 [ 736.534336] ? seqcount_lockdep_reader_access.constprop.0+0xc0/0xd0 [ 736.534619] ? __sanitizer_cov_trace_cmp4+0x1a/0x20 [ 736.534853] ? __sanitizer_cov_trace_const_cmp4+0x1a/0x20 [ 736.535104] ? security_file_fcntl+0x9d/0xd0 [ 736.535315] __x64_sys_fcntl+0x179/0x210 [ 736.535508] x64_sys_call+0x5b9/0x20d0 [ 736.535687] do_syscall_64+0x6d/0x140 [ 736.535866] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 736.536099] RIP: 0033:0x7f095de3ee5d [ 736.536273] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 93 af 1b 00 f7 d8 64 89 01 48 [ 736.537075] RSP: 002b:00007ffea8175048 EFLAGS: 00000217 ORIG_RAX: 0000000000000048 [ 736.537411] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f095de3ee5d [ 736.537736] RDX: 0000000000002400 RSI: 0000000000000004 RDI: 0000000000000003 [ 736.538053] RBP: 00007ffea8175060 R08: 00007ffea8175060 R09: 00007ffea8175060 [ 736.538371] R10: 00007ffea8175060 R11: 0000000000000217 R12: 00007ffea81751d8 [ 736.538689] R13: 000000000040547a R14: 0000000000407df8 R15: 00007f095e193000 [ 736.539023] </TASK> [ 736.539132] Kernel panic - not syncing: softlockup: hung tasks " Hope it's helpful. Thanks! --- If you don't need the following environment to reproduce the problem or if you already have one reproduced environment, please ignore the following information. How to reproduce: git clone https://gitlab.com/xupengfe/repro_vm_env.git cd repro_vm_env tar -xvf repro_vm_env.tar.gz cd repro_vm_env; ./start3.sh // it needs qemu-system-x86_64 and I used v7.1.0 // start3.sh will load bzImage_2241ab53cbb5cdb08a6b2d4688feb13971058f65 v6.2-rc5 kernel // You could change the bzImage_xxx as you want // Maybe you need to remove line "-drive if=pflash,format=raw,readonly=on,file=./OVMF_CODE.fd \" for different qemu version You could use below command to log in, there is no password for root. ssh -p 10023 root@localhost After login vm(virtual machine) successfully, you could transfer reproduced binary to the vm by below way, and reproduce the problem in vm: gcc -pthread -o repro repro.c scp -P 10023 repro root@localhost:/root/ Get the bzImage for target kernel: Please use target kconfig and copy it to kernel_src/.config make olddefconfig make -jx bzImage //x should equal or less than cpu num your pc has Fill the bzImage file into above start3.sh to load the target kernel in vm. Tips: If you already have qemu-system-x86_64, please ignore below info. If you want to install qemu v7.1.0 version: git clone https://github.com/qemu/qemu.git cd qemu git checkout -f v7.1.0 mkdir build cd build yum install -y ninja-build.x86_64 yum -y install libslirp-devel.x86_64 ../configure --target-list=x86_64-softmmu --enable-kvm --enable-vnc --enable-gtk --enable-sdl --enable-usb-redir --enable-slirp make make install Best Regards, Thanks! On 2023-04-17 at 10:46:22 -0000, tip-bot2 for Yang Jihong wrote: > The following commit has been merged into the perf/core branch of tip: > > Commit-ID: 15def34e2635ab7e0e96f1bc32e1b69609f14942 > Gitweb: https://git.kernel.org/tip/15def34e2635ab7e0e96f1bc32e1b69609f14942 > Author: Yang Jihong <yangjihong1(a)huawei.com> > AuthorDate: Mon, 27 Feb 2023 10:35:08 +08:00 > Committer: Peter Zijlstra <peterz(a)infradead.org> > CommitterDate: Fri, 14 Apr 2023 16:08:22 +02:00 > > perf/core: Fix hardlockup failure caused by perf throttle > > commit e050e3f0a71bf ("perf: Fix broken interrupt rate throttling") > introduces a change in throttling threshold judgment. Before this, > compare hwc->interrupts and max_samples_per_tick, then increase > hwc->interrupts by 1, but this commit reverses order of these two > behaviors, causing the semantics of max_samples_per_tick to change. > In literal sense of "max_samples_per_tick", if hwc->interrupts == > max_samples_per_tick, it should not be throttled, therefore, the judgment > condition should be changed to "hwc->interrupts > max_samples_per_tick". > > In fact, this may cause the hardlockup to fail, The minimum value of > max_samples_per_tick may be 1, in this case, the return value of > __perf_event_account_interrupt function is 1. > As a result, nmi_watchdog gets throttled, which would stop PMU (Use x86 > architecture as an example, see x86_pmu_handle_irq). > > Fixes: e050e3f0a71b ("perf: Fix broken interrupt rate throttling") > Signed-off-by: Yang Jihong <yangjihong1(a)huawei.com> > Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> > Link: https://lkml.kernel.org/r/20230227023508.102230-1-yangjihong1@huawei.com > --- > kernel/events/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/kernel/events/core.c b/kernel/events/core.c > index fb3e436..82b95b8 100644 > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -9433,8 +9433,8 @@ __perf_event_account_interrupt(struct perf_event *event, int throttle) > hwc->interrupts = 1; > } else { > hwc->interrupts++; > - if (unlikely(throttle > - && hwc->interrupts >= max_samples_per_tick)) { > + if (unlikely(throttle && > + hwc->interrupts > max_samples_per_tick)) { > __this_cpu_inc(perf_throttled_count); > tick_dep_set_cpu(smp_processor_id(), TICK_DEP_BIT_PERF_EVENTS); > hwc->interrupts = MAX_INTERRUPTS;

3 weeks, 4 days

1
0
0 0

[PATCH] perf/x86/intel: Limit the period on Haswell

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> Running the ltp test cve-2015-3290 concurrently reports the following warnings. perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: <NMI> ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330 Thanks to Thomas Gleixner's analysis, the issue is caused by the low initial period (1) of the frequency estimation algorithm, which triggers the defects of the HW, specifically erratum HSW11 and HSW143. (For the details, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/) The HSW11 requires a period larger than 100 for the INST_RETIRED.ALL event, but the initial period in the freq mode is 1. The erratum is the same as the BDM11, which has been supported in the kernel. A minimum period of 128 is enforced as well on HSW. HSW143 is regarding that the fixed counter 1 may overcount 32 with the Hyper-Threading is enabled. However, based on the test, the hardware has more issues than it tells. Besides the fixed counter 1, the message 'interrupt took too long' can be observed on any counter which was armed with a period < 32 and two events expired in the same NMI. A minimum period of 32 is enforced for the rest of the events. The recommended workaround code of the HSW143 is not implemented. Because it only addresses the issue for the fixed counter. It brings extra overhead through extra MSR writing. No related overcounting issue has been reported so far. Fixes: 3a632cb229bf ("perf/x86/intel: Add simple Haswell PMU support") Reported-by: Li Huafei <lihuafei1(a)huawei.com> Closes: https://lore.kernel.org/lkml/20240729223328.327835-1-lihuafei1@huawei.com/ Suggested-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: Vince Weaver <vincent.weaver(a)maine.edu> Cc: stable(a)vger.kernel.org --- arch/x86/events/intel/core.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index e8bd45556c30..605ed19043ed 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4634,6 +4634,25 @@ static enum hybrid_cpu_type adl_get_hybrid_cpu_type(void) return HYBRID_INTEL_CORE; } +static inline bool erratum_hsw11(struct perf_event *event) +{ + return (event->hw.config & INTEL_ARCH_EVENT_MASK) == + X86_CONFIG(.event=0xc0, .umask=0x01); +} + +/* + * The HSW11 requires a period larger than 100 which is the same as the BDM11. + * A minimum period of 128 is enforced as well for the INST_RETIRED.ALL. + * + * The message 'interrupt took too long' can be observed on any counter which + * was armed with a period < 32 and two events expired in the same NMI. + * A minimum period of 32 is enforced for the rest of the events. + */ +static void hsw_limit_period(struct perf_event *event, s64 *left) +{ + *left = max(*left, erratum_hsw11(event) ? 128 : 32); +} + /* * Broadwell: * @@ -4651,8 +4670,7 @@ static enum hybrid_cpu_type adl_get_hybrid_cpu_type(void) */ static void bdw_limit_period(struct perf_event *event, s64 *left) { - if ((event->hw.config & INTEL_ARCH_EVENT_MASK) == - X86_CONFIG(.event=0xc0, .umask=0x01)) { + if (erratum_hsw11(event)) { if (*left < 128) *left = 128; *left &= ~0x3fULL; @@ -6821,6 +6839,7 @@ __init int intel_pmu_init(void) x86_pmu.hw_config = hsw_hw_config; x86_pmu.get_event_constraints = hsw_get_event_constraints; + x86_pmu.limit_period = hsw_limit_period; x86_pmu.lbr_double_abort = true; extra_attr = boot_cpu_has(X86_FEATURE_RTM) ? hsw_format_attr : nhm_format_attr; -- 2.38.1

3 weeks, 5 days

2
1
0 0

[PATCH] crypto: sa2ul - fix memory leak in sa_cra_init_aead()

by Ma Ke

Currently the resource allocated by crypto_alloc_shash() is not freed in case crypto_alloc_aead() fails, resulting in memory leak. Add crypto_free_shash() to fix it. Found by code review. Cc: stable(a)vger.kernel.org Fixes: d2c8ac187fc9 ("crypto: sa2ul - Add AEAD algorithm support") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/crypto/sa2ul.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c index 461eca40e878..b5af621f7f17 100644 --- a/drivers/crypto/sa2ul.c +++ b/drivers/crypto/sa2ul.c @@ -1740,7 +1740,8 @@ static int sa_cra_init_aead(struct crypto_aead *tfm, const char *hash, ctx->shash = crypto_alloc_shash(hash, 0, CRYPTO_ALG_NEED_FALLBACK); if (IS_ERR(ctx->shash)) { dev_err(sa_k3_dev, "base driver %s couldn't be loaded\n", hash); - return PTR_ERR(ctx->shash); + ret = PTR_ERR(ctx->shash); + goto err_free_shash; } ctx->fallback.aead = crypto_alloc_aead(fallback, 0, @@ -1749,7 +1750,8 @@ static int sa_cra_init_aead(struct crypto_aead *tfm, const char *hash, if (IS_ERR(ctx->fallback.aead)) { dev_err(sa_k3_dev, "fallback driver %s couldn't be loaded\n", fallback); - return PTR_ERR(ctx->fallback.aead); + ret = PTR_ERR(ctx->fallback.aead); + goto err_free_shash; } crypto_aead_set_reqsize(tfm, sizeof(struct aead_request) + @@ -1757,19 +1759,23 @@ static int sa_cra_init_aead(struct crypto_aead *tfm, const char *hash, ret = sa_init_ctx_info(&ctx->enc, data); if (ret) - return ret; + goto err_free_shash; ret = sa_init_ctx_info(&ctx->dec, data); - if (ret) { - sa_free_ctx_info(&ctx->enc, data); - return ret; - } + if (ret) + goto err_free_ctx_info; dev_dbg(sa_k3_dev, "%s(0x%p) sc-ids(0x%x(0x%pad), 0x%x(0x%pad))\n", __func__, tfm, ctx->enc.sc_id, &ctx->enc.sc_phys, ctx->dec.sc_id, &ctx->dec.sc_phys); return ret; + +err_free_ctx_info: + sa_free_ctx_info(&ctx->enc, data); +err_free_shash: + crypto_free_shash(ctx->shash); + return ret; } static int sa_cra_init_aead_sha1(struct crypto_aead *tfm) -- 2.25.1

3 weeks, 5 days

2
1
0 0

[git:media_stage/master] media: venus: fix use after free bug in venus_remove due to race condition

by Hans Verkuil

This is an automatic generated email to let you know that the following patch were queued: Subject: media: venus: fix use after free bug in venus_remove due to race condition Author: Zheng Wang <zyytlz.wz(a)163.com> Date: Tue Jun 18 14:55:59 2024 +0530 in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove. Cc: stable(a)vger.kernel.org Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper functions") Signed-off-by: Zheng Wang <zyytlz.wz(a)163.com> Signed-off-by: Dikshita Agarwal <quic_dikshita(a)quicinc.com> Signed-off-by: Stanimir Varbanov <stanimir.k.varbanov(a)gmail.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> drivers/media/platform/qcom/venus/core.c | 1 + 1 file changed, 1 insertion(+) --- diff --git a/drivers/media/platform/qcom/venus/core.c b/drivers/media/platform/qcom/venus/core.c index 165c947a6703..84e95a46dfc9 100644 --- a/drivers/media/platform/qcom/venus/core.c +++ b/drivers/media/platform/qcom/venus/core.c @@ -430,6 +430,7 @@ static void venus_remove(struct platform_device *pdev) struct device *dev = core->dev; int ret; + cancel_delayed_work_sync(&core->work); ret = pm_runtime_get_sync(dev); WARN_ON(ret < 0);

3 weeks, 5 days

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024