Linux-stable-mirror March 2023

linux-stable-mirror@lists.linaro.org

449 participants
1888 discussions

FAILED: patch "[PATCH] scripts/tags.sh: fix incompatibility with PCRE2" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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>. Possible dependencies: 6ec363fc6142 ("scripts/tags.sh: fix incompatibility with PCRE2") 7394d2ebb651 ("scripts/tags.sh: Invoke 'realpath' via 'xargs'") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 6ec363fc6142226b9ab5a6528f65333d729d2b6b Mon Sep 17 00:00:00 2001 From: Carlos Llamas <cmllamas(a)google.com> Date: Wed, 15 Feb 2023 18:38:50 +0000 Subject: [PATCH] scripts/tags.sh: fix incompatibility with PCRE2 Starting with release 10.38 PCRE2 drops default support for using \K in lookaround patterns as described in [1]. Unfortunately, scripts/tags.sh relies on such functionality to collect all_compiled_soures() leading to the following error: $ make COMPILED_SOURCE=1 tags GEN tags grep: \K is not allowed in lookarounds (but see PCRE2_EXTRA_ALLOW_LOOKAROUND_BSK) The usage of \K for this pattern was introduced in commit 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") which speeds up the generation of tags significantly. In order to fix this issue without compromising the performance we can switch over to an equivalent sed expression. The same matching pattern is preserved here except \K is replaced with a backreference \1. [1] https://www.pcre.org/current/doc/html/pcre2syntax.html#SEC11 Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Cristian Ciocaltea <cristian.ciocaltea(a)collabora.com> Cc: Masahiro Yamada <masahiroy(a)kernel.org> Cc: Jialu Xu <xujialu(a)vimux.org> Cc: Vipin Sharma <vipinsh(a)google.com> Cc: stable(a)vger.kernel.org Fixes: 4f491bb6ea2a ("scripts/tags.sh: collect compiled source precisely") Signed-off-by: Carlos Llamas <cmllamas(a)google.com> Link: https://lore.kernel.org/r/20230215183850.3353198-1-cmllamas@google.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/scripts/tags.sh b/scripts/tags.sh index 1ad45f17179a..6b9001853890 100755 --- a/scripts/tags.sh +++ b/scripts/tags.sh @@ -98,7 +98,7 @@ all_compiled_sources() { echo include/generated/autoconf.h find $ignore -name "*.cmd" -exec \ - grep -Poh '(?(?=^source_.* \K).*|(?=^ \K\S).*(?= \\))' {} \+ | + sed -n -E 's/^source_.* (.*)/\1/p; s/^ (\S.*) \\/\1/p' {} \+ | awk '!a[$0]++' } | xargs realpath -esq $([ -z "$KBUILD_ABS_SRCTREE" ] && echo --relative-to=.) | sort -u

2 years, 1 month

Re: [PATCH v2 0/3] wifi: rtw88: USB fixes

by Sascha Hauer

On Fri, Feb 10, 2023 at 12:16:29PM +0100, Sascha Hauer wrote: > This series addresses issues for the recently added RTW88 USB support > reported by Andreas Henriksson and also our customer. > > The hardware can't handle urbs that have a size of multiple of the > bulkout_size (usually 512 bytes). The symptom is that the hardware > stalls completely. The issue can be reproduced by sending a suitably > sized ping packet from the device: > > ping -s 394 <somehost> > > (It's 394 bytes here on a RTL8822CU and RTL8821CU, the actual size may > differ on other chips, it was 402 bytes on a RTL8723DU) > > Other than that qsel was not set correctly. The sympton here is that > only one of multiple bulk endpoints was used to send data. > > Changes since v1: > - Use URB_ZERO_PACKET to let the USB host controller handle it automatically > rather than working around the issue. > > Sascha Hauer (3): > wifi: rtw88: usb: Set qsel correctly > wifi: rtw88: usb: send Zero length packets if necessary > wifi: rtw88: usb: drop now unnecessary URB size check These patches went in upstream as: 7869b834fb07c wifi: rtw88: usb: Set qsel correctly 07ce9fa6ab0e5 wifi: rtw88: usb: send Zero length packets if necessary 462c8db6a0116 wifi: rtw88: usb: drop now unnecessary URB size check These patches make the RTW88 USB support much more reliable. Can they be picked for the current 6.2 stable series please? Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |

2 years, 1 month

[PATCH AUTOSEL 6.2 01/60] drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Tab 3 X90F

by Sasha Levin

From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit 8a238d7f7eea7592e0764bc3b9e79e7c6354b04c ] The Lenovo Yoga Tab 3 X90F has a portrait 1600x2560 LCD used in landscape mode, add a quirk for this. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221127181539.104223-1-hdego… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_panel_orientation_quirks.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c b/drivers/gpu/drm/drm_panel_orientation_quirks.c index 3659f0465a724..23d63a4d42d9c 100644 --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c @@ -127,6 +127,12 @@ static const struct drm_dmi_panel_orientation_data lcd1600x2560_leftside_up = { .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP, }; +static const struct drm_dmi_panel_orientation_data lcd1600x2560_rightside_up = { + .width = 1600, + .height = 2560, + .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP, +}; + static const struct dmi_system_id orientation_data[] = { { /* Acer One 10 (S1003) */ .matches = { @@ -331,6 +337,13 @@ static const struct dmi_system_id orientation_data[] = { DMI_MATCH(DMI_BIOS_VERSION, "BLADE_21"), }, .driver_data = (void *)&lcd1200x1920_rightside_up, + }, { /* Lenovo Yoga Tab 3 X90F */ + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Intel Corporation"), + DMI_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"), + DMI_MATCH(DMI_PRODUCT_VERSION, "Blade3-10A-001"), + }, + .driver_data = (void *)&lcd1600x2560_rightside_up, }, { /* Nanote UMPC-01 */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "RWC CO.,LTD"), -- 2.39.0

2 years, 1 month

[PATCH AUTOSEL 6.2 01/53] wifi: ath9k: Fix use-after-free in ath9k_hif_usb_disconnect()

by Sasha Levin

From: Minsuk Kang <linuxlovemin(a)yonsei.ac.kr> [ Upstream commit f099c5c9e2ba08a379bd354a82e05ef839ae29ac ] This patch fixes a use-after-free in ath9k that occurs in ath9k_hif_usb_disconnect() when ath9k_destroy_wmi() is trying to access 'drv_priv' that has already been freed by ieee80211_free_hw(), called by ath9k_htc_hw_deinit(). The patch moves ath9k_destroy_wmi() before ieee80211_free_hw(). Note that urbs from the driver should be killed before freeing 'wmi' with ath9k_destroy_wmi() as their callbacks will access 'wmi'. Found by a modified version of syzkaller. ================================================================== BUG: KASAN: use-after-free in ath9k_destroy_wmi+0x38/0x40 Read of size 8 at addr ffff8881069132a0 by task kworker/0:1/7 CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #131 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Workqueue: usb_hub_wq hub_event Call Trace: dump_stack_lvl+0x8e/0xd1 print_address_description.constprop.0.cold+0x93/0x334 ? ath9k_destroy_wmi+0x38/0x40 ? ath9k_destroy_wmi+0x38/0x40 kasan_report.cold+0x83/0xdf ? ath9k_destroy_wmi+0x38/0x40 ath9k_destroy_wmi+0x38/0x40 ath9k_hif_usb_disconnect+0x329/0x3f0 ? ath9k_hif_usb_suspend+0x120/0x120 ? usb_disable_interface+0xfc/0x180 usb_unbind_interface+0x19b/0x7e0 ? usb_autoresume_device+0x50/0x50 device_release_driver_internal+0x44d/0x520 bus_remove_device+0x2e5/0x5a0 device_del+0x5b2/0xe30 ? __device_link_del+0x370/0x370 ? usb_remove_ep_devs+0x43/0x80 ? remove_intf_ep_devs+0x112/0x1a0 usb_disable_device+0x1e3/0x5a0 usb_disconnect+0x267/0x870 hub_event+0x168d/0x3950 ? rcu_read_lock_sched_held+0xa1/0xd0 ? hub_port_debounce+0x2e0/0x2e0 ? check_irq_usage+0x860/0xf20 ? drain_workqueue+0x281/0x360 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x92b/0x1460 ? pwq_dec_nr_in_flight+0x330/0x330 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x95/0xe00 ? __kthread_parkme+0x115/0x1e0 ? process_one_work+0x1460/0x1460 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30 The buggy address belongs to the page: page:ffffea00041a44c0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x106913 flags: 0x200000000000000(node=0|zone=2) raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as freed page last allocated via order 3, migratetype Unmovable, gfp_mask 0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), pid 7, ts 38347963444, free_ts 41399957635 prep_new_page+0x1aa/0x240 get_page_from_freelist+0x159a/0x27c0 __alloc_pages+0x2da/0x6a0 alloc_pages+0xec/0x1e0 kmalloc_order+0x39/0xf0 kmalloc_order_trace+0x19/0x120 __kmalloc+0x308/0x390 wiphy_new_nm+0x6f5/0x1dd0 ieee80211_alloc_hw_nm+0x36d/0x2230 ath9k_htc_probe_device+0x9d/0x1e10 ath9k_htc_hw_init+0x34/0x50 ath9k_hif_usb_firmware_cb+0x25f/0x4e0 request_firmware_work_func+0x131/0x240 process_one_work+0x92b/0x1460 worker_thread+0x95/0xe00 kthread+0x3a1/0x480 page last free stack trace: free_pcp_prepare+0x3d3/0x7f0 free_unref_page+0x1e/0x3d0 device_release+0xa4/0x240 kobject_put+0x186/0x4c0 put_device+0x20/0x30 ath9k_htc_disconnect_device+0x1cf/0x2c0 ath9k_htc_hw_deinit+0x26/0x30 ath9k_hif_usb_disconnect+0x2d9/0x3f0 usb_unbind_interface+0x19b/0x7e0 device_release_driver_internal+0x44d/0x520 bus_remove_device+0x2e5/0x5a0 device_del+0x5b2/0xe30 usb_disable_device+0x1e3/0x5a0 usb_disconnect+0x267/0x870 hub_event+0x168d/0x3950 process_one_work+0x92b/0x1460 Memory state around the buggy address: ffff888106913180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888106913200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888106913280: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888106913300: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888106913380: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ================================================================== Reported-by: Dokyung Song <dokyungs(a)yonsei.ac.kr> Reported-by: Jisoo Jang <jisoo.jang(a)yonsei.ac.kr> Reported-by: Minsuk Kang <linuxlovemin(a)yonsei.ac.kr> Signed-off-by: Minsuk Kang <linuxlovemin(a)yonsei.ac.kr> Acked-by: Toke Høiland-Jørgensen <toke(a)toke.dk> Signed-off-by: Kalle Valo <quic_kvalo(a)quicinc.com> Link: https://lore.kernel.org/r/20221205014308.1617597-1-linuxlovemin@yonsei.ac.kr Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/wireless/ath/ath9k/hif_usb.c | 2 -- drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c index 1a2e0c7eeb023..86ede591dafaf 100644 --- a/drivers/net/wireless/ath/ath9k/hif_usb.c +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c @@ -1411,8 +1411,6 @@ static void ath9k_hif_usb_disconnect(struct usb_interface *interface) if (hif_dev->flags & HIF_USB_READY) { ath9k_htc_hw_deinit(hif_dev->htc_handle, unplugged); - ath9k_hif_usb_dev_deinit(hif_dev); - ath9k_destroy_wmi(hif_dev->htc_handle->drv_priv); ath9k_htc_hw_free(hif_dev->htc_handle); } diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c index 07ac88fb1c577..96a3185a96d75 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c @@ -988,6 +988,8 @@ void ath9k_htc_disconnect_device(struct htc_target *htc_handle, bool hotunplug) ath9k_deinit_device(htc_handle->drv_priv); ath9k_stop_wmi(htc_handle->drv_priv); + ath9k_hif_usb_dealloc_urbs((struct hif_device_usb *)htc_handle->hif_dev); + ath9k_destroy_wmi(htc_handle->drv_priv); ieee80211_free_hw(htc_handle->drv_priv->hw); } } -- 2.39.0

2 years, 1 month

Re: [Android 5.10] kernel BUG in ext4_free_blocks (2)

by syzbot

This bug is marked as fixed by commit: ext4: block range must be validated before use in ext4_mb_clear_bb() But I can't find it in the tested trees[1] for more than 90 days. Is it a correct commit? Please update it by replying: #syz fix: exact-commit-title Until then the bug is still considered open and new crashes with the same signature are ignored. Kernel: Android 5.10 Dashboard link: https://syzkaller.appspot.com/bug?extid=15cd994e273307bf5cfa --- [1] I expect the commit to be present in: 1. android12-5.10-lts branch of https://android.googlesource.com/kernel/common

2 years, 1 month

[PATCH AUTOSEL 6.2 01/21] ARM: OMAP2+: omap4-common: Fix refcount leak bug

by Sasha Levin

From: Liang He <windhl(a)126.com> [ Upstream commit 7c32919a378782c95c72bc028b5c30dfe8c11f82 ] In omap4_sram_init(), of_find_compatible_node() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore. Signed-off-by: Liang He <windhl(a)126.com> Message-Id: <20220628112939.160737-1-windhl(a)126.com> Signed-off-by: Tony Lindgren <tony(a)atomide.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/arm/mach-omap2/omap4-common.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c index 6d1eb4eefefe5..d9ed2a5dcd5ef 100644 --- a/arch/arm/mach-omap2/omap4-common.c +++ b/arch/arm/mach-omap2/omap4-common.c @@ -140,6 +140,7 @@ static int __init omap4_sram_init(void) __func__); else sram_sync = (void __iomem *)gen_pool_alloc(sram_pool, PAGE_SIZE); + of_node_put(np); return 0; } -- 2.39.0

2 years, 1 month

Odlitky-pořádek

by Alan Beran

Dobré ráno, Hledám firmy, které jsou ochotné uvažovat o změně dodavatele nabízejícího hliníkové tlakové odlitky. Garantujeme opakovatelnou kvalitu detailů s nízkou drsností povrchu a vysokou odolností proti korozi. Výrobky chráníme pasivačním povlakem na bázi chemie Surtec 650 v plně automatizovaném procesu ponoru. Detaily práškově lakujeme na robotické lince od renomované švýcarské firmy. Pokud vidíte příležitost ke spolupráci, kontaktujte mě. Alan Beran

2 years, 1 month

Servicio de la flota

by Antonio Valverde

Buenos días: Le escribo para hablarle sobre una de las mejores herramientas GPS en el mercado. La herramienta, que me gustaría presentarle brevemente, dispone de muchas funciones útiles para su trabajo, que optimizan los procesos de transporte y le ayudan a realizar tareas de campo de manera más eficiente. ¿Quiere conocer los detalles? Atentamente, Antonio Valverde

2 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2023