From: Sasha Levin Date: Sat, 8 Feb 2025 16:15:25 +0000 (-0500) Subject: Fixes for 6.6 X-Git-Tag: v6.6.77~44 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=462fe7714776029c943fdafc98be2d402ea8529f;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 6.6 Signed-off-by: Sasha Levin --- diff --git a/queue-6.6/apei-ghes-have-ghes-honor-the-panic-setting.patch b/queue-6.6/apei-ghes-have-ghes-honor-the-panic-setting.patch new file mode 100644 index 0000000000..104a9761d8 --- /dev/null +++ b/queue-6.6/apei-ghes-have-ghes-honor-the-panic-setting.patch @@ -0,0 +1,72 @@ +From 47932ef80cbe49904fe84532fc3d44bc867d6a0d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 Jan 2025 13:52:24 +0100 +Subject: APEI: GHES: Have GHES honor the panic= setting + +From: Borislav Petkov + +[ Upstream commit 5c0e00a391dd0099fe95991bb2f962848d851916 ] + +The GHES driver overrides the panic= setting by force-rebooting the +system after a fatal hw error has been reported. The intent being that +such an error would be reported earlier. + +However, this is not optimal when a hard-to-debug issue requires long +time to reproduce and when that happens, the box will get rebooted after +30 seconds and thus destroy the whole hw context of when the error +happened. + +So rip out the default GHES panic timeout and honor the global one. + +In the panic disabled (panic=0) case, the error will still be logged to +dmesg for later inspection and if panic after a hw error is really +required, then that can be controlled the usual way - use panic= on the +cmdline or set it in the kernel .config's CONFIG_PANIC_TIMEOUT. + +Reported-by: Feng Tang +Signed-off-by: Borislav Petkov (AMD) +Reviewed-by: Feng Tang +Reviewed-by: Ira Weiny +Link: https://patch.msgid.link/20250113125224.GFZ4UMiNtWIJvgpveU@fat_crate.local +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/acpi/apei/ghes.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c +index ab2a82cb1b0b4..3aadc632d7dd5 100644 +--- a/drivers/acpi/apei/ghes.c ++++ b/drivers/acpi/apei/ghes.c +@@ -170,8 +170,6 @@ static struct gen_pool *ghes_estatus_pool; + static struct ghes_estatus_cache __rcu *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE]; + static atomic_t ghes_estatus_cache_alloced; + +-static int ghes_panic_timeout __read_mostly = 30; +- + static void __iomem *ghes_map(u64 pfn, enum fixed_addresses fixmap_idx) + { + phys_addr_t paddr; +@@ -899,14 +897,16 @@ static void __ghes_panic(struct ghes *ghes, + struct acpi_hest_generic_status *estatus, + u64 buf_paddr, enum fixed_addresses fixmap_idx) + { ++ const char *msg = GHES_PFX "Fatal hardware error"; ++ + __ghes_print_estatus(KERN_EMERG, ghes->generic, estatus); + + ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx); + +- /* reboot to log the error! */ + if (!panic_timeout) +- panic_timeout = ghes_panic_timeout; +- panic("Fatal hardware error!"); ++ pr_emerg("%s but panic disabled\n", msg); ++ ++ panic(msg); + } + + static int ghes_proc(struct ghes *ghes) +-- +2.39.5 + diff --git a/queue-6.6/arm64-mm-ensure-adequate-huge_max_hstate.patch b/queue-6.6/arm64-mm-ensure-adequate-huge_max_hstate.patch new file mode 100644 index 0000000000..252fa847b3 --- /dev/null +++ b/queue-6.6/arm64-mm-ensure-adequate-huge_max_hstate.patch @@ -0,0 +1,56 @@ +From 156c14e5de5d322d6af2089cae044ac5065110ca Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 2 Dec 2024 12:14:07 +0530 +Subject: arm64/mm: Ensure adequate HUGE_MAX_HSTATE + +From: Anshuman Khandual + +[ Upstream commit 1e5823c8e86de83a43d59a522b4de29066d3b306 ] + +This asserts that HUGE_MAX_HSTATE is sufficient enough preventing potential +hugetlb_max_hstate runtime overflow in hugetlb_add_hstate() thus triggering +a BUG_ON() there after. + +Cc: Catalin Marinas +Cc: Will Deacon +Cc: Ard Biesheuvel +Cc: Ryan Roberts +Cc: Mark Rutland +Cc: linux-arm-kernel@lists.infradead.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Anshuman Khandual +Reviewed-by: Ryan Roberts +Reviewed-by: Gavin Shan +Link: https://lore.kernel.org/r/20241202064407.53807-1-anshuman.khandual@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + arch/arm64/mm/hugetlbpage.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c +index 13fd592228b18..a5e1588780b2c 100644 +--- a/arch/arm64/mm/hugetlbpage.c ++++ b/arch/arm64/mm/hugetlbpage.c +@@ -526,6 +526,18 @@ pte_t huge_ptep_clear_flush(struct vm_area_struct *vma, + + static int __init hugetlbpage_init(void) + { ++ /* ++ * HugeTLB pages are supported on maximum four page table ++ * levels (PUD, CONT PMD, PMD, CONT PTE) for a given base ++ * page size, corresponding to hugetlb_add_hstate() calls ++ * here. ++ * ++ * HUGE_MAX_HSTATE should at least match maximum supported ++ * HugeTLB page sizes on the platform. Any new addition to ++ * supported HugeTLB page sizes will also require changing ++ * HUGE_MAX_HSTATE as well. ++ */ ++ BUILD_BUG_ON(HUGE_MAX_HSTATE < 4); + if (pud_sect_supported()) + hugetlb_add_hstate(PUD_SHIFT - PAGE_SHIFT); + +-- +2.39.5 + diff --git a/queue-6.6/asoc-amd-add-acpi-dependency-to-fix-build-error.patch b/queue-6.6/asoc-amd-add-acpi-dependency-to-fix-build-error.patch new file mode 100644 index 0000000000..9cfc806051 --- /dev/null +++ b/queue-6.6/asoc-amd-add-acpi-dependency-to-fix-build-error.patch @@ -0,0 +1,48 @@ +From 463f35b6471f17418e807dee893c14770b100020 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 10 Jan 2025 01:15:47 +0800 +Subject: ASoC: amd: Add ACPI dependency to fix build error + +From: Yu-Chun Lin + +[ Upstream commit 7e24ec93aecd12e33d31e38e5af4625553bbc727 ] + +As reported by the kernel test robot, the following error occurs: + + sound/soc/amd/yc/acp6x-mach.c: In function 'acp6x_probe': +>> sound/soc/amd/yc/acp6x-mach.c:573:15: error: implicit declaration of function 'acpi_evaluate_integer'; did you mean 'acpi_evaluate_object'? [-Werror=implicit-function-declaration] + 573 | ret = acpi_evaluate_integer(handle, "_WOV", NULL, &dmic_status); + | ^~~~~~~~~~~~~~~~~~~~~ + | acpi_evaluate_object + cc1: some warnings being treated as errors + +The function 'acpi_evaluate_integer' and its prototype in 'acpi_bus.h' +are only available when 'CONFIG_ACPI' is enabled. Add a 'depends on ACPI' +directive in Kconfig to ensure proper compilation. + +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-kbuild-all/202501090345.pBIDRTym-lkp@intel.com/ +Signed-off-by: Yu-Chun Lin +Link: https://patch.msgid.link/20250109171547.362412-1-eleanor15x@gmail.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/amd/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/sound/soc/amd/Kconfig b/sound/soc/amd/Kconfig +index 273688c053172..0b6a01c6bbb1b 100644 +--- a/sound/soc/amd/Kconfig ++++ b/sound/soc/amd/Kconfig +@@ -105,7 +105,7 @@ config SND_SOC_AMD_ACP6x + config SND_SOC_AMD_YC_MACH + tristate "AMD YC support for DMIC" + select SND_SOC_DMIC +- depends on SND_SOC_AMD_ACP6x ++ depends on SND_SOC_AMD_ACP6x && ACPI + help + This option enables machine driver for Yellow Carp platform + using dmic. ACP IP has PDM Decoder block with DMA controller. +-- +2.39.5 + diff --git a/queue-6.6/asoc-soc-pcm-don-t-use-soc_pcm_ret-on-.prepare-callb.patch b/queue-6.6/asoc-soc-pcm-don-t-use-soc_pcm_ret-on-.prepare-callb.patch new file mode 100644 index 0000000000..4e97d9f75b --- /dev/null +++ b/queue-6.6/asoc-soc-pcm-don-t-use-soc_pcm_ret-on-.prepare-callb.patch @@ -0,0 +1,104 @@ +From 8b4554b8269976b6a036481c0e868c05aaa69726 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 13 Dec 2024 01:21:10 +0000 +Subject: ASoC: soc-pcm: don't use soc_pcm_ret() on .prepare callback + +From: Kuninori Morimoto + +[ Upstream commit 301c26a018acb94dd537a4418cefa0f654500c6f ] + +commit 1f5664351410 ("ASoC: lower "no backend DAIs enabled for ... Port" +log severity") ignores -EINVAL error message on common soc_pcm_ret(). +It is used from many functions, ignoring -EINVAL is over-kill. + +The reason why -EINVAL was ignored was it really should only be used +upon invalid parameters coming from userspace and in that case we don't +want to log an error since we do not want to give userspace a way to do +a denial-of-service attack on the syslog / diskspace. + +So don't use soc_pcm_ret() on .prepare callback is better idea. + +Link: https://lore.kernel.org/r/87v7vptzap.wl-kuninori.morimoto.gx@renesas.com +Cc: Hans de Goede +Signed-off-by: Kuninori Morimoto +Link: https://patch.msgid.link/87bjxg8jju.wl-kuninori.morimoto.gx@renesas.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + sound/soc/soc-pcm.c | 32 ++++++++++++++++++++++++++++---- + 1 file changed, 28 insertions(+), 4 deletions(-) + +diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c +index 511446a30c057..60248a6820aac 100644 +--- a/sound/soc/soc-pcm.c ++++ b/sound/soc/soc-pcm.c +@@ -38,7 +38,6 @@ static inline int _soc_pcm_ret(struct snd_soc_pcm_runtime *rtd, + switch (ret) { + case -EPROBE_DEFER: + case -ENOTSUPP: +- case -EINVAL: + break; + default: + dev_err(rtd->dev, +@@ -902,7 +901,13 @@ static int __soc_pcm_prepare(struct snd_soc_pcm_runtime *rtd, + } + + out: +- return soc_pcm_ret(rtd, ret); ++ /* ++ * Don't use soc_pcm_ret() on .prepare callback to lower error log severity ++ * ++ * We don't want to log an error since we do not want to give userspace a way to do a ++ * denial-of-service attack on the syslog / diskspace. ++ */ ++ return ret; + } + + /* PCM prepare ops for non-DPCM streams */ +@@ -914,6 +919,13 @@ static int soc_pcm_prepare(struct snd_pcm_substream *substream) + snd_soc_dpcm_mutex_lock(rtd); + ret = __soc_pcm_prepare(rtd, substream); + snd_soc_dpcm_mutex_unlock(rtd); ++ ++ /* ++ * Don't use soc_pcm_ret() on .prepare callback to lower error log severity ++ * ++ * We don't want to log an error since we do not want to give userspace a way to do a ++ * denial-of-service attack on the syslog / diskspace. ++ */ + return ret; + } + +@@ -2461,7 +2473,13 @@ int dpcm_be_dai_prepare(struct snd_soc_pcm_runtime *fe, int stream) + be->dpcm[stream].state = SND_SOC_DPCM_STATE_PREPARE; + } + +- return soc_pcm_ret(fe, ret); ++ /* ++ * Don't use soc_pcm_ret() on .prepare callback to lower error log severity ++ * ++ * We don't want to log an error since we do not want to give userspace a way to do a ++ * denial-of-service attack on the syslog / diskspace. ++ */ ++ return ret; + } + + static int dpcm_fe_dai_prepare(struct snd_pcm_substream *substream) +@@ -2501,7 +2519,13 @@ static int dpcm_fe_dai_prepare(struct snd_pcm_substream *substream) + dpcm_set_fe_update_state(fe, stream, SND_SOC_DPCM_UPDATE_NO); + snd_soc_dpcm_mutex_unlock(fe); + +- return soc_pcm_ret(fe, ret); ++ /* ++ * Don't use soc_pcm_ret() on .prepare callback to lower error log severity ++ * ++ * We don't want to log an error since we do not want to give userspace a way to do a ++ * denial-of-service attack on the syslog / diskspace. ++ */ ++ return ret; + } + + static int dpcm_run_update_shutdown(struct snd_soc_pcm_runtime *fe, int stream) +-- +2.39.5 + diff --git a/queue-6.6/bluetooth-mgmt-fix-slab-use-after-free-read-in-mgmt_.patch b/queue-6.6/bluetooth-mgmt-fix-slab-use-after-free-read-in-mgmt_.patch new file mode 100644 index 0000000000..ec03b95aeb --- /dev/null +++ b/queue-6.6/bluetooth-mgmt-fix-slab-use-after-free-read-in-mgmt_.patch @@ -0,0 +1,130 @@ +From 191a1f7946494928dc29d87304c55701ecff9a11 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 24 Dec 2024 05:06:16 +0300 +Subject: Bluetooth: MGMT: Fix slab-use-after-free Read in + mgmt_remove_adv_monitor_sync + +From: Mazin Al Haddad + +[ Upstream commit 26fbd3494a7dd26269cb0817c289267dbcfdec06 ] + +This fixes the following crash: + +================================================================== +BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 +Read of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961 + +CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 +Workqueue: hci0 hci_cmd_sync_work +Call Trace: + + __dump_stack lib/dump_stack.c:94 [inline] + dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 + print_address_description mm/kasan/report.c:378 [inline] + print_report+0x169/0x550 mm/kasan/report.c:489 + kasan_report+0x143/0x180 mm/kasan/report.c:602 + mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543 + hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 + process_one_work kernel/workqueue.c:3229 [inline] + process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 + worker_thread+0x870/0xd30 kernel/workqueue.c:3391 + kthread+0x2f0/0x390 kernel/kthread.c:389 + ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 + ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 + + +Allocated by task 16026: + kasan_save_stack mm/kasan/common.c:47 [inline] + kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 + poison_kmalloc_redzone mm/kasan/common.c:377 [inline] + __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 + kasan_kmalloc include/linux/kasan.h:260 [inline] + __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314 + kmalloc_noprof include/linux/slab.h:901 [inline] + kzalloc_noprof include/linux/slab.h:1037 [inline] + mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269 + mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296 + remove_adv_monitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568 + hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712 + hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832 + sock_sendmsg_nosec net/socket.c:711 [inline] + __sock_sendmsg+0x221/0x270 net/socket.c:726 + sock_write_iter+0x2d7/0x3f0 net/socket.c:1147 + new_sync_write fs/read_write.c:586 [inline] + vfs_write+0xaeb/0xd30 fs/read_write.c:679 + ksys_write+0x18f/0x2b0 fs/read_write.c:731 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + +Freed by task 16022: + kasan_save_stack mm/kasan/common.c:47 [inline] + kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 + kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 + poison_slab_object mm/kasan/common.c:247 [inline] + __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 + kasan_slab_free include/linux/kasan.h:233 [inline] + slab_free_hook mm/slub.c:2338 [inline] + slab_free mm/slub.c:4598 [inline] + kfree+0x196/0x420 mm/slub.c:4746 + mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259 + __mgmt_power_off+0x183/0x430 net/bluetooth/mgmt.c:9550 + hci_dev_close_sync+0x6c4/0x11c0 net/bluetooth/hci_sync.c:5208 + hci_dev_do_close net/bluetooth/hci_core.c:483 [inline] + hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508 + sock_do_ioctl+0x158/0x460 net/socket.c:1209 + sock_ioctl+0x626/0x8e0 net/socket.c:1328 + vfs_ioctl fs/ioctl.c:51 [inline] + __do_sys_ioctl fs/ioctl.c:906 [inline] + __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + +Reported-by: syzbot+479aff51bb361ef5aa18@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=479aff51bb361ef5aa18 +Tested-by: syzbot+479aff51bb361ef5aa18@syzkaller.appspotmail.com +Signed-off-by: Mazin Al Haddad +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/mgmt.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c +index e3440f0d7d9d9..b36254107ef57 100644 +--- a/net/bluetooth/mgmt.c ++++ b/net/bluetooth/mgmt.c +@@ -5453,10 +5453,16 @@ static void mgmt_remove_adv_monitor_complete(struct hci_dev *hdev, + { + struct mgmt_rp_remove_adv_monitor rp; + struct mgmt_pending_cmd *cmd = data; +- struct mgmt_cp_remove_adv_monitor *cp = cmd->param; ++ struct mgmt_cp_remove_adv_monitor *cp; ++ ++ if (status == -ECANCELED || ++ cmd != pending_find(MGMT_OP_REMOVE_ADV_MONITOR, hdev)) ++ return; + + hci_dev_lock(hdev); + ++ cp = cmd->param; ++ + rp.monitor_handle = cp->monitor_handle; + + if (!status) +@@ -5474,6 +5480,10 @@ static void mgmt_remove_adv_monitor_complete(struct hci_dev *hdev, + static int mgmt_remove_adv_monitor_sync(struct hci_dev *hdev, void *data) + { + struct mgmt_pending_cmd *cmd = data; ++ ++ if (cmd != pending_find(MGMT_OP_REMOVE_ADV_MONITOR, hdev)) ++ return -ECANCELED; ++ + struct mgmt_cp_remove_adv_monitor *cp = cmd->param; + u16 handle = __le16_to_cpu(cp->monitor_handle); + +-- +2.39.5 + diff --git a/queue-6.6/btrfs-convert-bug_on-in-btrfs_reloc_cow_block-to-pro.patch b/queue-6.6/btrfs-convert-bug_on-in-btrfs_reloc_cow_block-to-pro.patch new file mode 100644 index 0000000000..9a12d8a17e --- /dev/null +++ b/queue-6.6/btrfs-convert-bug_on-in-btrfs_reloc_cow_block-to-pro.patch @@ -0,0 +1,51 @@ +From 1797924819e332eaf12678adb83e297648f73ceb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 3 Oct 2024 11:43:03 -0400 +Subject: btrfs: convert BUG_ON in btrfs_reloc_cow_block() to proper error + handling + +From: Josef Bacik + +[ Upstream commit 6a4730b325aaa48f7a5d5ba97aff0a955e2d9cec ] + +This BUG_ON is meant to catch backref cache problems, but these can +arise from either bugs in the backref cache or corruption in the extent +tree. Fix it to be a proper error. + +Reviewed-by: Boris Burkov +Signed-off-by: Josef Bacik +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/relocation.c | 14 ++++++++++++-- + 1 file changed, 12 insertions(+), 2 deletions(-) + +diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c +index 299eac696eb42..537e184b4b1df 100644 +--- a/fs/btrfs/relocation.c ++++ b/fs/btrfs/relocation.c +@@ -4378,8 +4378,18 @@ int btrfs_reloc_cow_block(struct btrfs_trans_handle *trans, + WARN_ON(!first_cow && level == 0); + + node = rc->backref_cache.path[level]; +- BUG_ON(node->bytenr != buf->start && +- node->new_bytenr != buf->start); ++ ++ /* ++ * If node->bytenr != buf->start and node->new_bytenr != ++ * buf->start then we've got the wrong backref node for what we ++ * expected to see here and the cache is incorrect. ++ */ ++ if (unlikely(node->bytenr != buf->start && node->new_bytenr != buf->start)) { ++ btrfs_err(fs_info, ++"bytenr %llu was found but our backref cache was expecting %llu or %llu", ++ buf->start, node->bytenr, node->new_bytenr); ++ return -EUCLEAN; ++ } + + btrfs_backref_drop_node_buffer(node); + atomic_inc(&cow->refs); +-- +2.39.5 + diff --git a/queue-6.6/btrfs-fix-assertion-failure-when-splitting-ordered-e.patch b/queue-6.6/btrfs-fix-assertion-failure-when-splitting-ordered-e.patch new file mode 100644 index 0000000000..1e5d2059bb --- /dev/null +++ b/queue-6.6/btrfs-fix-assertion-failure-when-splitting-ordered-e.patch @@ -0,0 +1,182 @@ +From 6f68fe03471f9ce150253111657bb307538b9454 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 Jan 2025 15:01:08 +0000 +Subject: btrfs: fix assertion failure when splitting ordered extent after + transaction abort + +From: Filipe Manana + +[ Upstream commit 0d85f5c2dd91df6b5da454406756f463ba923b69 ] + +If while we are doing a direct IO write a transaction abort happens, we +mark all existing ordered extents with the BTRFS_ORDERED_IOERR flag (done +at btrfs_destroy_ordered_extents()), and then after that if we enter +btrfs_split_ordered_extent() and the ordered extent has bytes left +(meaning we have a bio that doesn't cover the whole ordered extent, see +details at btrfs_extract_ordered_extent()), we will fail on the following +assertion at btrfs_split_ordered_extent(): + + ASSERT(!(flags & ~BTRFS_ORDERED_TYPE_FLAGS)); + +because the BTRFS_ORDERED_IOERR flag is set and the definition of +BTRFS_ORDERED_TYPE_FLAGS is just the union of all flags that identify the +type of write (regular, nocow, prealloc, compressed, direct IO, encoded). + +Fix this by returning an error from btrfs_extract_ordered_extent() if we +find the BTRFS_ORDERED_IOERR flag in the ordered extent. The error will +be the error that resulted in the transaction abort or -EIO if no +transaction abort happened. + +This was recently reported by syzbot with the following trace: + + FAULT_INJECTION: forcing a failure. + name failslab, interval 1, probability 0, space 0, times 1 + CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 + Call Trace: + + __dump_stack lib/dump_stack.c:94 [inline] + dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 + fail_dump lib/fault-inject.c:53 [inline] + should_fail_ex+0x3b0/0x4e0 lib/fault-inject.c:154 + should_failslab+0xac/0x100 mm/failslab.c:46 + slab_pre_alloc_hook mm/slub.c:4072 [inline] + slab_alloc_node mm/slub.c:4148 [inline] + __do_kmalloc_node mm/slub.c:4297 [inline] + __kmalloc_noprof+0xdd/0x4c0 mm/slub.c:4310 + kmalloc_noprof include/linux/slab.h:905 [inline] + kzalloc_noprof include/linux/slab.h:1037 [inline] + btrfs_chunk_alloc_add_chunk_item+0x244/0x1100 fs/btrfs/volumes.c:5742 + reserve_chunk_space+0x1ca/0x2c0 fs/btrfs/block-group.c:4292 + check_system_chunk fs/btrfs/block-group.c:4319 [inline] + do_chunk_alloc fs/btrfs/block-group.c:3891 [inline] + btrfs_chunk_alloc+0x77b/0xf80 fs/btrfs/block-group.c:4187 + find_free_extent_update_loop fs/btrfs/extent-tree.c:4166 [inline] + find_free_extent+0x42d1/0x5810 fs/btrfs/extent-tree.c:4579 + btrfs_reserve_extent+0x422/0x810 fs/btrfs/extent-tree.c:4672 + btrfs_new_extent_direct fs/btrfs/direct-io.c:186 [inline] + btrfs_get_blocks_direct_write+0x706/0xfa0 fs/btrfs/direct-io.c:321 + btrfs_dio_iomap_begin+0xbb7/0x1180 fs/btrfs/direct-io.c:525 + iomap_iter+0x697/0xf60 fs/iomap/iter.c:90 + __iomap_dio_rw+0xeb9/0x25b0 fs/iomap/direct-io.c:702 + btrfs_dio_write fs/btrfs/direct-io.c:775 [inline] + btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 + btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 + do_iter_readv_writev+0x600/0x880 + vfs_writev+0x376/0xba0 fs/read_write.c:1050 + do_pwritev fs/read_write.c:1146 [inline] + __do_sys_pwritev2 fs/read_write.c:1204 [inline] + __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + RIP: 0033:0x7f1281f85d29 + RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 + RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 + RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 + RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 + R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 + R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 + + BTRFS error (device loop0 state A): Transaction aborted (error -12) + BTRFS: error (device loop0 state A) in btrfs_chunk_alloc_add_chunk_item:5745: errno=-12 Out of memory + BTRFS info (device loop0 state EA): forced readonly + assertion failed: !(flags & ~BTRFS_ORDERED_TYPE_FLAGS), in fs/btrfs/ordered-data.c:1234 + ------------[ cut here ]------------ + kernel BUG at fs/btrfs/ordered-data.c:1234! + Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI + CPU: 0 UID: 0 PID: 5321 Comm: syz.0.0 Not tainted 6.13.0-rc5-syzkaller #0 + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 + RIP: 0010:btrfs_split_ordered_extent+0xd8d/0xe20 fs/btrfs/ordered-data.c:1234 + RSP: 0018:ffffc9000d1df2b8 EFLAGS: 00010246 + RAX: 0000000000000057 RBX: 000000000006a000 RCX: 9ce21886c4195300 + RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 + RBP: 0000000000000091 R08: ffffffff817f0a3c R09: 1ffff92001a3bdf4 + R10: dffffc0000000000 R11: fffff52001a3bdf5 R12: 1ffff1100a45f401 + R13: ffff8880522fa018 R14: dffffc0000000000 R15: 000000000006a000 + FS: 00007f12819fe6c0(0000) GS:ffff88801fc00000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 0000557750bd7da8 CR3: 00000000400ea000 CR4: 0000000000352ef0 + DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 + DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 + Call Trace: + + btrfs_extract_ordered_extent fs/btrfs/direct-io.c:702 [inline] + btrfs_dio_submit_io+0x4be/0x6d0 fs/btrfs/direct-io.c:737 + iomap_dio_submit_bio fs/iomap/direct-io.c:85 [inline] + iomap_dio_bio_iter+0x1022/0x1740 fs/iomap/direct-io.c:447 + __iomap_dio_rw+0x13b7/0x25b0 fs/iomap/direct-io.c:703 + btrfs_dio_write fs/btrfs/direct-io.c:775 [inline] + btrfs_direct_write+0x610/0xa30 fs/btrfs/direct-io.c:880 + btrfs_do_write_iter+0x2a0/0x760 fs/btrfs/file.c:1397 + do_iter_readv_writev+0x600/0x880 + vfs_writev+0x376/0xba0 fs/read_write.c:1050 + do_pwritev fs/read_write.c:1146 [inline] + __do_sys_pwritev2 fs/read_write.c:1204 [inline] + __se_sys_pwritev2+0x196/0x2b0 fs/read_write.c:1195 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + RIP: 0033:0x7f1281f85d29 + RSP: 002b:00007f12819fe038 EFLAGS: 00000246 ORIG_RAX: 0000000000000148 + RAX: ffffffffffffffda RBX: 00007f1282176080 RCX: 00007f1281f85d29 + RDX: 0000000000000001 RSI: 0000000020000240 RDI: 0000000000000005 + RBP: 00007f12819fe090 R08: 0000000000000000 R09: 0000000000000003 + R10: 0000000000007000 R11: 0000000000000246 R12: 0000000000000002 + R13: 0000000000000000 R14: 00007f1282176080 R15: 00007ffcb9e23328 + + Modules linked in: + ---[ end trace 0000000000000000 ]--- + RIP: 0010:btrfs_split_ordered_extent+0xd8d/0xe20 fs/btrfs/ordered-data.c:1234 + RSP: 0018:ffffc9000d1df2b8 EFLAGS: 00010246 + RAX: 0000000000000057 RBX: 000000000006a000 RCX: 9ce21886c4195300 + RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 + RBP: 0000000000000091 R08: ffffffff817f0a3c R09: 1ffff92001a3bdf4 + R10: dffffc0000000000 R11: fffff52001a3bdf5 R12: 1ffff1100a45f401 + R13: ffff8880522fa018 R14: dffffc0000000000 R15: 000000000006a000 + FS: 00007f12819fe6c0(0000) GS:ffff88801fc00000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 0000557750bd7da8 CR3: 00000000400ea000 CR4: 0000000000352ef0 + DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 + DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 + +In this case the transaction abort was due to (an injected) memory +allocation failure when attempting to allocate a new chunk. + +Reported-by: syzbot+f60d8337a5c8e8d92a77@syzkaller.appspotmail.com +Link: https://lore.kernel.org/linux-btrfs/6777f2dd.050a0220.178762.0045.GAE@google.com/ +Fixes: 52b1fdca23ac ("btrfs: handle completed ordered extents in btrfs_split_ordered_extent") +Reviewed-by: Qu Wenruo +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/ordered-data.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c +index 8a3c46cb67f53..86d846eb5ed49 100644 +--- a/fs/btrfs/ordered-data.c ++++ b/fs/btrfs/ordered-data.c +@@ -1171,6 +1171,18 @@ struct btrfs_ordered_extent *btrfs_split_ordered_extent( + */ + if (WARN_ON_ONCE(len >= ordered->num_bytes)) + return ERR_PTR(-EINVAL); ++ /* ++ * If our ordered extent had an error there's no point in continuing. ++ * The error may have come from a transaction abort done either by this ++ * task or some other concurrent task, and the transaction abort path ++ * iterates over all existing ordered extents and sets the flag ++ * BTRFS_ORDERED_IOERR on them. ++ */ ++ if (unlikely(flags & (1U << BTRFS_ORDERED_IOERR))) { ++ const int fs_error = BTRFS_FS_ERROR(fs_info); ++ ++ return fs_error ? ERR_PTR(fs_error) : ERR_PTR(-EIO); ++ } + /* We cannot split partially completed ordered extents. */ + if (ordered->bytes_left) { + ASSERT(!(flags & ~BTRFS_ORDERED_TYPE_FLAGS)); +-- +2.39.5 + diff --git a/queue-6.6/btrfs-fix-data-race-when-accessing-the-inode-s-disk_.patch b/queue-6.6/btrfs-fix-data-race-when-accessing-the-inode-s-disk_.patch new file mode 100644 index 0000000000..95a13c971c --- /dev/null +++ b/queue-6.6/btrfs-fix-data-race-when-accessing-the-inode-s-disk_.patch @@ -0,0 +1,85 @@ +From 528bb5557534c31aa82d3964b00450deaddb2d7c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 3 Dec 2024 15:56:51 +0800 +Subject: btrfs: fix data race when accessing the inode's disk_i_size at + btrfs_drop_extents() + +From: Hao-ran Zheng + +[ Upstream commit 5324c4e10e9c2ce307a037e904c0d9671d7137d9 ] + +A data race occurs when the function `insert_ordered_extent_file_extent()` +and the function `btrfs_inode_safe_disk_i_size_write()` are executed +concurrently. The function `insert_ordered_extent_file_extent()` is not +locked when reading inode->disk_i_size, causing +`btrfs_inode_safe_disk_i_size_write()` to cause data competition when +writing inode->disk_i_size, thus affecting the value of `modify_tree`. + +The specific call stack that appears during testing is as follows: + + ============DATA_RACE============ + btrfs_drop_extents+0x89a/0xa060 [btrfs] + insert_reserved_file_extent+0xb54/0x2960 [btrfs] + insert_ordered_extent_file_extent+0xff5/0x1760 [btrfs] + btrfs_finish_one_ordered+0x1b85/0x36a0 [btrfs] + btrfs_finish_ordered_io+0x37/0x60 [btrfs] + finish_ordered_fn+0x3e/0x50 [btrfs] + btrfs_work_helper+0x9c9/0x27a0 [btrfs] + process_scheduled_works+0x716/0xf10 + worker_thread+0xb6a/0x1190 + kthread+0x292/0x330 + ret_from_fork+0x4d/0x80 + ret_from_fork_asm+0x1a/0x30 + ============OTHER_INFO============ + btrfs_inode_safe_disk_i_size_write+0x4ec/0x600 [btrfs] + btrfs_finish_one_ordered+0x24c7/0x36a0 [btrfs] + btrfs_finish_ordered_io+0x37/0x60 [btrfs] + finish_ordered_fn+0x3e/0x50 [btrfs] + btrfs_work_helper+0x9c9/0x27a0 [btrfs] + process_scheduled_works+0x716/0xf10 + worker_thread+0xb6a/0x1190 + kthread+0x292/0x330 + ret_from_fork+0x4d/0x80 + ret_from_fork_asm+0x1a/0x30 + ================================= + +The main purpose of the check of the inode's disk_i_size is to avoid +taking write locks on a btree path when we have a write at or beyond +EOF, since in these cases we don't expect to find extent items in the +root to drop. However if we end up taking write locks due to a data +race on disk_i_size, everything is still correct, we only add extra +lock contention on the tree in case there's concurrency from other tasks. +If the race causes us to not take write locks when we actually need them, +then everything is functionally correct as well, since if we find out we +have extent items to drop and we took read locks (modify_tree set to 0), +we release the path and retry again with write locks. + +Since this data race does not affect the correctness of the function, +it is a harmless data race, use data_race() to check inode->disk_i_size. + +Reviewed-by: Filipe Manana +Signed-off-by: Hao-ran Zheng +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/file.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c +index fc6c91773bc89..c2d0c62b087c2 100644 +--- a/fs/btrfs/file.c ++++ b/fs/btrfs/file.c +@@ -241,7 +241,7 @@ int btrfs_drop_extents(struct btrfs_trans_handle *trans, + if (args->drop_cache) + btrfs_drop_extent_map_range(inode, args->start, args->end - 1, false); + +- if (args->start >= inode->disk_i_size && !args->replace_extent) ++ if (data_race(args->start >= inode->disk_i_size) && !args->replace_extent) + modify_tree = 0; + + update_refs = (root->root_key.objectid != BTRFS_TREE_LOG_OBJECTID); +-- +2.39.5 + diff --git a/queue-6.6/btrfs-fix-use-after-free-when-attempting-to-join-an-.patch b/queue-6.6/btrfs-fix-use-after-free-when-attempting-to-join-an-.patch new file mode 100644 index 0000000000..b2d0cbc823 --- /dev/null +++ b/queue-6.6/btrfs-fix-use-after-free-when-attempting-to-join-an-.patch @@ -0,0 +1,212 @@ +From c7b759d04422e008c6ceeb93b45b53cde85669e1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 20 Jan 2025 17:26:10 +0000 +Subject: btrfs: fix use-after-free when attempting to join an aborted + transaction + +From: Filipe Manana + +[ Upstream commit e2f0943cf37305dbdeaf9846e3c941451bcdef63 ] + +When we are trying to join the current transaction and if it's aborted, +we read its 'aborted' field after unlocking fs_info->trans_lock and +without holding any extra reference count on it. This means that a +concurrent task that is aborting the transaction may free the transaction +before we read its 'aborted' field, leading to a use-after-free. + +Fix this by reading the 'aborted' field while holding fs_info->trans_lock +since any freeing task must first acquire that lock and set +fs_info->running_transaction to NULL before freeing the transaction. + +This was reported by syzbot and Dmitry with the following stack traces +from KASAN: + + ================================================================== + BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 + Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128 + + CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0 + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 + Workqueue: events_unbound btrfs_async_reclaim_data_space + Call Trace: + + __dump_stack lib/dump_stack.c:94 [inline] + dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 + print_address_description mm/kasan/report.c:378 [inline] + print_report+0x169/0x550 mm/kasan/report.c:489 + kasan_report+0x143/0x180 mm/kasan/report.c:602 + join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278 + start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 + flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803 + btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321 + process_one_work kernel/workqueue.c:3236 [inline] + process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317 + worker_thread+0x870/0xd30 kernel/workqueue.c:3398 + kthread+0x2f0/0x390 kernel/kthread.c:389 + ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 + ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 + + + Allocated by task 5315: + kasan_save_stack mm/kasan/common.c:47 [inline] + kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 + poison_kmalloc_redzone mm/kasan/common.c:377 [inline] + __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 + kasan_kmalloc include/linux/kasan.h:260 [inline] + __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 + kmalloc_noprof include/linux/slab.h:901 [inline] + join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308 + start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697 + btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572 + lookup_open fs/namei.c:3649 [inline] + open_last_lookups fs/namei.c:3748 [inline] + path_openat+0x1c03/0x3590 fs/namei.c:3984 + do_filp_open+0x27f/0x4e0 fs/namei.c:4014 + do_sys_openat2+0x13e/0x1d0 fs/open.c:1402 + do_sys_open fs/open.c:1417 [inline] + __do_sys_creat fs/open.c:1495 [inline] + __se_sys_creat fs/open.c:1489 [inline] + __x64_sys_creat+0x123/0x170 fs/open.c:1489 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + + Freed by task 5336: + kasan_save_stack mm/kasan/common.c:47 [inline] + kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 + kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 + poison_slab_object mm/kasan/common.c:247 [inline] + __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 + kasan_slab_free include/linux/kasan.h:233 [inline] + slab_free_hook mm/slub.c:2353 [inline] + slab_free mm/slub.c:4613 [inline] + kfree+0x196/0x430 mm/slub.c:4761 + cleanup_transaction fs/btrfs/transaction.c:2063 [inline] + btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598 + insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757 + btrfs_balance+0x992/0x10c0 fs/btrfs/volumes.c:4633 + btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3670 + vfs_ioctl fs/ioctl.c:51 [inline] + __do_sys_ioctl fs/ioctl.c:906 [inline] + __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + + The buggy address belongs to the object at ffff888011839000 + which belongs to the cache kmalloc-2k of size 2048 + The buggy address is located 36 bytes inside of + freed 2048-byte region [ffff888011839000, ffff888011839800) + + The buggy address belongs to the physical page: + page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11838 + head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 + flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff) + page_type: f5(slab) + raw: 00fff00000000040 ffff88801ac42000 ffffea0000493400 dead000000000002 + raw: 0000000000000000 0000000000080008 00000001f5000000 0000000000000000 + head: 00fff00000000040 ffff88801ac42000 ffffea0000493400 dead000000000002 + head: 0000000000000000 0000000000080008 00000001f5000000 0000000000000000 + head: 00fff00000000003 ffffea0000460e01 ffffffffffffffff 0000000000000000 + head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000 + page dumped because: kasan: bad access detected + page_owner tracks the page as allocated + page last allocated via order 3, migratetype Unmovable, gfp_mask 0xd20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC), pid 57, tgid 57 (kworker/0:2), ts 67248182943, free_ts 67229742023 + set_page_owner include/linux/page_owner.h:32 [inline] + post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1558 + prep_new_page mm/page_alloc.c:1566 [inline] + get_page_from_freelist+0x365c/0x37a0 mm/page_alloc.c:3476 + __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4753 + alloc_pages_mpol_noprof+0x3e1/0x780 mm/mempolicy.c:2269 + alloc_slab_page+0x6a/0x110 mm/slub.c:2423 + allocate_slab+0x5a/0x2b0 mm/slub.c:2589 + new_slab mm/slub.c:2642 [inline] + ___slab_alloc+0xc27/0x14a0 mm/slub.c:3830 + __slab_alloc+0x58/0xa0 mm/slub.c:3920 + __slab_alloc_node mm/slub.c:3995 [inline] + slab_alloc_node mm/slub.c:4156 [inline] + __do_kmalloc_node mm/slub.c:4297 [inline] + __kmalloc_node_track_caller_noprof+0x2e9/0x4c0 mm/slub.c:4317 + kmalloc_reserve+0x111/0x2a0 net/core/skbuff.c:609 + __alloc_skb+0x1f3/0x440 net/core/skbuff.c:678 + alloc_skb include/linux/skbuff.h:1323 [inline] + alloc_skb_with_frags+0xc3/0x820 net/core/skbuff.c:6612 + sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2884 + sock_alloc_send_skb include/net/sock.h:1803 [inline] + mld_newpack+0x1c3/0xaf0 net/ipv6/mcast.c:1747 + add_grhead net/ipv6/mcast.c:1850 [inline] + add_grec+0x1492/0x19a0 net/ipv6/mcast.c:1988 + mld_send_cr net/ipv6/mcast.c:2114 [inline] + mld_ifc_work+0x691/0xd90 net/ipv6/mcast.c:2651 + page last free pid 5300 tgid 5300 stack trace: + reset_page_owner include/linux/page_owner.h:25 [inline] + free_pages_prepare mm/page_alloc.c:1127 [inline] + free_unref_page+0xd3f/0x1010 mm/page_alloc.c:2659 + __slab_free+0x2c2/0x380 mm/slub.c:4524 + qlink_free mm/kasan/quarantine.c:163 [inline] + qlist_free_all+0x9a/0x140 mm/kasan/quarantine.c:179 + kasan_quarantine_reduce+0x14f/0x170 mm/kasan/quarantine.c:286 + __kasan_slab_alloc+0x23/0x80 mm/kasan/common.c:329 + kasan_slab_alloc include/linux/kasan.h:250 [inline] + slab_post_alloc_hook mm/slub.c:4119 [inline] + slab_alloc_node mm/slub.c:4168 [inline] + __do_kmalloc_node mm/slub.c:4297 [inline] + __kmalloc_noprof+0x236/0x4c0 mm/slub.c:4310 + kmalloc_noprof include/linux/slab.h:905 [inline] + kzalloc_noprof include/linux/slab.h:1037 [inline] + fib_create_info+0xc14/0x25b0 net/ipv4/fib_semantics.c:1435 + fib_table_insert+0x1f6/0x1f20 net/ipv4/fib_trie.c:1231 + fib_magic+0x3d8/0x620 net/ipv4/fib_frontend.c:1112 + fib_add_ifaddr+0x40c/0x5e0 net/ipv4/fib_frontend.c:1156 + fib_netdev_event+0x375/0x490 net/ipv4/fib_frontend.c:1494 + notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85 + __dev_notify_flags+0x207/0x400 + dev_change_flags+0xf0/0x1a0 net/core/dev.c:9045 + do_setlink+0xc90/0x4210 net/core/rtnetlink.c:3109 + rtnl_changelink net/core/rtnetlink.c:3723 [inline] + __rtnl_newlink net/core/rtnetlink.c:3875 [inline] + rtnl_newlink+0x1bb6/0x2210 net/core/rtnetlink.c:4012 + + Memory state around the buggy address: + ffff888011838f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + ffff888011838f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + >ffff888011839000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ^ + ffff888011839080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ffff888011839100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb + ================================================================== + +Reported-by: syzbot+45212e9d87a98c3f5b42@syzkaller.appspotmail.com +Link: https://lore.kernel.org/linux-btrfs/678e7da5.050a0220.303755.007c.GAE@google.com/ +Reported-by: Dmitry Vyukov +Link: https://lore.kernel.org/linux-btrfs/CACT4Y+ZFBdo7pT8L2AzM=vegZwjp-wNkVJZQf0Ta3vZqtExaSw@mail.gmail.com/ +Fixes: 871383be592b ("btrfs: add missing unlocks to transaction abort paths") +Reviewed-by: Johannes Thumshirn +Reviewed-by: Qu Wenruo +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/transaction.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c +index 0548072c642fb..aa03db69a0164 100644 +--- a/fs/btrfs/transaction.c ++++ b/fs/btrfs/transaction.c +@@ -278,8 +278,10 @@ static noinline int join_transaction(struct btrfs_fs_info *fs_info, + cur_trans = fs_info->running_transaction; + if (cur_trans) { + if (TRANS_ABORTED(cur_trans)) { ++ const int abort_error = cur_trans->aborted; ++ + spin_unlock(&fs_info->trans_lock); +- return cur_trans->aborted; ++ return abort_error; + } + if (btrfs_blocked_trans_types[cur_trans->state] & type) { + spin_unlock(&fs_info->trans_lock); +-- +2.39.5 + diff --git a/queue-6.6/clk-qcom-make-gcc_8150-depend-on-qcom_gdsc.patch b/queue-6.6/clk-qcom-make-gcc_8150-depend-on-qcom_gdsc.patch new file mode 100644 index 0000000000..06b6a3fd33 --- /dev/null +++ b/queue-6.6/clk-qcom-make-gcc_8150-depend-on-qcom_gdsc.patch @@ -0,0 +1,41 @@ +From d37f5eb21302f5236456d3868d2011c397e9d506 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 26 Oct 2024 12:58:13 +0200 +Subject: clk: qcom: Make GCC_8150 depend on QCOM_GDSC + +From: Konrad Dybcio + +[ Upstream commit 1474149c4209943b37a2c01b82f07ba39465e5fe ] + +Like all other non-ancient Qualcomm clock drivers, QCOM_GDSC is +required, as the GCC driver defines and instantiates a bunch of GDSCs. + +Add the missing dependency. + +Reported-by: Vladimir Zapolskiy +Closes: https://lore.kernel.org/linux-arm-msm/ab85f2ae-6c97-4fbb-a15b-31cc9e1f77fc@linaro.org/ +Signed-off-by: Konrad Dybcio +Reviewed-by: Dmitry Baryshkov +Reviewed-by: Vladimir Zapolskiy +Link: https://lore.kernel.org/r/20241026-topic-8150gcc_kconfig-v1-1-3772013d8804@oss.qualcomm.com +Signed-off-by: Bjorn Andersson +Signed-off-by: Sasha Levin +--- + drivers/clk/qcom/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig +index a79b837583894..1de1661037b1b 100644 +--- a/drivers/clk/qcom/Kconfig ++++ b/drivers/clk/qcom/Kconfig +@@ -881,6 +881,7 @@ config SM_GCC_7150 + config SM_GCC_8150 + tristate "SM8150 Global Clock Controller" + depends on ARM64 || COMPILE_TEST ++ select QCOM_GDSC + help + Support for the global clock controller on SM8150 devices. + Say Y if you want to use peripheral devices such as UART, +-- +2.39.5 + diff --git a/queue-6.6/drm-amd-display-fix-mode-cutoff-in-dsc-passthrough-t.patch b/queue-6.6/drm-amd-display-fix-mode-cutoff-in-dsc-passthrough-t.patch new file mode 100644 index 0000000000..5cc480b146 --- /dev/null +++ b/queue-6.6/drm-amd-display-fix-mode-cutoff-in-dsc-passthrough-t.patch @@ -0,0 +1,61 @@ +From 9950bb626c6899e81eb1d9cfcce6e9e6001b5add Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 2 Dec 2024 13:30:37 -0500 +Subject: drm/amd/display: Fix Mode Cutoff in DSC Passthrough to DP2.1 Monitor + +From: Fangzhi Zuo + +[ Upstream commit e56ad45e991128bf4db160b75a1d9f647a341d8f ] + +Source --> DP2.1 MST hub --> DP1.4/2.1 monitor + +When change from DP1.4 to DP2.1 from monitor manual, modes higher than +4k120 are all cutoff by mode validation. Switch back to DP1.4 gets all +the modes up to 4k240 available to be enabled by dsc passthrough. + +[why] +Compared to DP1.4 link from hub to monitor, DP2.1 link has larger +full_pbn value that causes overflow in the process of doing conversion +from pbn to kbps. + +[how] +Change the data type accordingly to fit into the data limit during +conversion calculation. + +Tested-by: Daniel Wheeler +Reviewed-by: Wayne Lin +Signed-off-by: Fangzhi Zuo +Signed-off-by: Rodrigo Siqueira +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +index 385a5a75fdf87..5858e288b3fd6 100644 +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c +@@ -1578,16 +1578,16 @@ int pre_validate_dsc(struct drm_atomic_state *state, + return ret; + } + +-static unsigned int kbps_from_pbn(unsigned int pbn) ++static uint32_t kbps_from_pbn(unsigned int pbn) + { +- unsigned int kbps = pbn; ++ uint64_t kbps = (uint64_t)pbn; + + kbps *= (1000000 / PEAK_FACTOR_X1000); + kbps *= 8; + kbps *= 54; + kbps /= 64; + +- return kbps; ++ return (uint32_t)kbps; + } + + static bool is_dsc_common_config_possible(struct dc_stream_state *stream, +-- +2.39.5 + diff --git a/queue-6.6/drm-amd-display-use-eld_mutex-to-protect-access-to-c.patch b/queue-6.6/drm-amd-display-use-eld_mutex-to-protect-access-to-c.patch new file mode 100644 index 0000000000..9b2e3ec863 --- /dev/null +++ b/queue-6.6/drm-amd-display-use-eld_mutex-to-protect-access-to-c.patch @@ -0,0 +1,40 @@ +From 238986e3e9ad3c8f8813aa5589cf741b646b1895 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Dec 2024 11:43:07 +0200 +Subject: drm/amd/display: use eld_mutex to protect access to connector->eld + +From: Dmitry Baryshkov + +[ Upstream commit 819bee01eea06282d7bda17d46caf29cae4f6d84 ] + +Reading access to connector->eld can happen at the same time the +drm_edid_to_eld() updates the data. Take the newly added eld_mutex in +order to protect connector->eld from concurrent access. + +Reviewed-by: Maxime Ripard +Reviewed-by: Harry Wentland +Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-4-c9bce1ee8bea@linaro.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +index 8a152f4974d3c..aab99df3ba1ae 100644 +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -955,8 +955,10 @@ static int amdgpu_dm_audio_component_get_eld(struct device *kdev, int port, + continue; + + *enabled = true; ++ mutex_lock(&connector->eld_mutex); + ret = drm_eld_size(connector->eld); + memcpy(buf, connector->eld, min(max_bytes, ret)); ++ mutex_unlock(&connector->eld_mutex); + + break; + } +-- +2.39.5 + diff --git a/queue-6.6/drm-bridge-anx7625-use-eld_mutex-to-protect-access-t.patch b/queue-6.6/drm-bridge-anx7625-use-eld_mutex-to-protect-access-t.patch new file mode 100644 index 0000000000..62462bbcd8 --- /dev/null +++ b/queue-6.6/drm-bridge-anx7625-use-eld_mutex-to-protect-access-t.patch @@ -0,0 +1,40 @@ +From 6f02abb7a5136f44513a838910ced32bdc8f907e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Dec 2024 11:43:05 +0200 +Subject: drm/bridge: anx7625: use eld_mutex to protect access to + connector->eld + +From: Dmitry Baryshkov + +[ Upstream commit e72bf423a60afd744d13e40ab2194044a3af5217 ] + +Reading access to connector->eld can happen at the same time the +drm_edid_to_eld() updates the data. Take the newly added eld_mutex in +order to protect connector->eld from concurrent access. + +Reviewed-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-2-c9bce1ee8bea@linaro.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/bridge/analogix/anx7625.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c b/drivers/gpu/drm/bridge/analogix/anx7625.c +index 412c6575e87b7..ddf944651c55a 100644 +--- a/drivers/gpu/drm/bridge/analogix/anx7625.c ++++ b/drivers/gpu/drm/bridge/analogix/anx7625.c +@@ -2014,8 +2014,10 @@ static int anx7625_audio_get_eld(struct device *dev, void *data, + memset(buf, 0, len); + } else { + dev_dbg(dev, "audio copy eld\n"); ++ mutex_lock(&ctx->connector->eld_mutex); + memcpy(buf, ctx->connector->eld, + min(sizeof(ctx->connector->eld), len)); ++ mutex_unlock(&ctx->connector->eld_mutex); + } + + return 0; +-- +2.39.5 + diff --git a/queue-6.6/drm-bridge-it6505-change-definition-max_hdcp_down_st.patch b/queue-6.6/drm-bridge-it6505-change-definition-max_hdcp_down_st.patch new file mode 100644 index 0000000000..d5985edc3a --- /dev/null +++ b/queue-6.6/drm-bridge-it6505-change-definition-max_hdcp_down_st.patch @@ -0,0 +1,41 @@ +From 627af969e55c007375ed7421d5d7e1e1212c1e1f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 30 Dec 2024 18:51:22 +0800 +Subject: drm/bridge: it6505: Change definition MAX_HDCP_DOWN_STREAM_COUNT + +From: Hermes Wu + +[ Upstream commit 85597bc0d70c287ba41f17d14d3d857a38a3d727 ] + +A HDCP source device shall support max downstream to 127 devices. +Change definition MAX_HDCP_DOWN_STREAM_COUNT to 127 + +KSVs shall save for DRM blocked devices check. +This results in struct it6505 growth by ~0.5 KiB. + +Reviewed-by: Dmitry Baryshkov +Signed-off-by: Hermes Wu +Reviewed-by: AngeloGioacchino Del Regno +Signed-off-by: Dmitry Baryshkov +Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-4-e0fdd4844703@ite.corp-partner.google.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/bridge/ite-it6505.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c +index 24c5a926af8d1..bd4c8f5d55a64 100644 +--- a/drivers/gpu/drm/bridge/ite-it6505.c ++++ b/drivers/gpu/drm/bridge/ite-it6505.c +@@ -295,7 +295,7 @@ + #define MAX_LANE_COUNT 4 + #define MAX_LINK_RATE HBR + #define AUTO_TRAIN_RETRY 3 +-#define MAX_HDCP_DOWN_STREAM_COUNT 10 ++#define MAX_HDCP_DOWN_STREAM_COUNT 127 + #define MAX_CR_LEVEL 0x03 + #define MAX_EQ_LEVEL 0x03 + #define AUX_WAIT_TIMEOUT_MS 15 +-- +2.39.5 + diff --git a/queue-6.6/drm-bridge-it6505-fix-hdcp-bstatus-check.patch b/queue-6.6/drm-bridge-it6505-fix-hdcp-bstatus-check.patch new file mode 100644 index 0000000000..5536551214 --- /dev/null +++ b/queue-6.6/drm-bridge-it6505-fix-hdcp-bstatus-check.patch @@ -0,0 +1,54 @@ +From 54cdb601c6a0652b78d5d78935920be9c17dcb1b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 30 Dec 2024 18:51:23 +0800 +Subject: drm/bridge: it6505: fix HDCP Bstatus check + +From: Hermes Wu + +[ Upstream commit 0fd2ff47d8c207fa3173661de04bb9e8201c0ad2 ] + +When HDCP is activated, +a DisplayPort source receiving CP_IRQ from the sink +shall check Bstatus from DPCD and process the corresponding value + +Reviewed-by: Dmitry Baryshkov +Signed-off-by: Hermes Wu +Reviewed-by: AngeloGioacchino Del Regno +Signed-off-by: Dmitry Baryshkov +Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-5-e0fdd4844703@ite.corp-partner.google.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/bridge/ite-it6505.c | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c +index bd4c8f5d55a64..f037288e841ac 100644 +--- a/drivers/gpu/drm/bridge/ite-it6505.c ++++ b/drivers/gpu/drm/bridge/ite-it6505.c +@@ -2309,14 +2309,20 @@ static int it6505_process_hpd_irq(struct it6505 *it6505) + DRM_DEV_DEBUG_DRIVER(dev, "dp_irq_vector = 0x%02x", dp_irq_vector); + + if (dp_irq_vector & DP_CP_IRQ) { +- it6505_set_bits(it6505, REG_HDCP_TRIGGER, HDCP_TRIGGER_CPIRQ, +- HDCP_TRIGGER_CPIRQ); +- + bstatus = it6505_dpcd_read(it6505, DP_AUX_HDCP_BSTATUS); + if (bstatus < 0) + return bstatus; + + DRM_DEV_DEBUG_DRIVER(dev, "Bstatus = 0x%02x", bstatus); ++ ++ /*Check BSTATUS when recive CP_IRQ */ ++ if (bstatus & DP_BSTATUS_R0_PRIME_READY && ++ it6505->hdcp_status == HDCP_AUTH_GOING) ++ it6505_set_bits(it6505, REG_HDCP_TRIGGER, HDCP_TRIGGER_CPIRQ, ++ HDCP_TRIGGER_CPIRQ); ++ else if (bstatus & (DP_BSTATUS_REAUTH_REQ | DP_BSTATUS_LINK_FAILURE) && ++ it6505->hdcp_status == HDCP_AUTH_DONE) ++ it6505_start_hdcp(it6505); + } + + ret = drm_dp_dpcd_read_link_status(&it6505->aux, link_status); +-- +2.39.5 + diff --git a/queue-6.6/drm-bridge-it6505-fix-hdcp-cts-compare-v-matching.patch b/queue-6.6/drm-bridge-it6505-fix-hdcp-cts-compare-v-matching.patch new file mode 100644 index 0000000000..644a1bebd4 --- /dev/null +++ b/queue-6.6/drm-bridge-it6505-fix-hdcp-cts-compare-v-matching.patch @@ -0,0 +1,78 @@ +From b2a802d7dcfd635ece232b9731461a33a40f6352 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 30 Dec 2024 18:51:26 +0800 +Subject: drm/bridge: it6505: fix HDCP CTS compare V matching + +From: Hermes Wu + +[ Upstream commit 0989c02c7a5c887c70afeae80c64d0291624e1a7 ] + +When HDCP negotiation with a repeater device. +Checking SHA V' matching must retry 3 times before restarting HDCP. + +Signed-off-by: Hermes Wu +Reviewed-by: AngeloGioacchino Del Regno +Signed-off-by: Dmitry Baryshkov +Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-8-e0fdd4844703@ite.corp-partner.google.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/bridge/ite-it6505.c | 32 +++++++++++++++++------------ + 1 file changed, 19 insertions(+), 13 deletions(-) + +diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c +index f9f67e172eeee..552d33c4325af 100644 +--- a/drivers/gpu/drm/bridge/ite-it6505.c ++++ b/drivers/gpu/drm/bridge/ite-it6505.c +@@ -2020,7 +2020,7 @@ static bool it6505_hdcp_part2_ksvlist_check(struct it6505 *it6505) + { + struct device *dev = it6505->dev; + u8 av[5][4], bv[5][4]; +- int i, err; ++ int i, err, retry; + + i = it6505_setup_sha1_input(it6505, it6505->sha1_input); + if (i <= 0) { +@@ -2029,22 +2029,28 @@ static bool it6505_hdcp_part2_ksvlist_check(struct it6505 *it6505) + } + + it6505_sha1_digest(it6505, it6505->sha1_input, i, (u8 *)av); ++ /*1B-05 V' must retry 3 times */ ++ for (retry = 0; retry < 3; retry++) { ++ err = it6505_get_dpcd(it6505, DP_AUX_HDCP_V_PRIME(0), (u8 *)bv, ++ sizeof(bv)); + +- err = it6505_get_dpcd(it6505, DP_AUX_HDCP_V_PRIME(0), (u8 *)bv, +- sizeof(bv)); ++ if (err < 0) { ++ dev_err(dev, "Read V' value Fail %d", retry); ++ continue; ++ } + +- if (err < 0) { +- dev_err(dev, "Read V' value Fail"); +- return false; +- } ++ for (i = 0; i < 5; i++) { ++ if (bv[i][3] != av[i][0] || bv[i][2] != av[i][1] || ++ av[i][1] != av[i][2] || bv[i][0] != av[i][3]) ++ break; + +- for (i = 0; i < 5; i++) +- if (bv[i][3] != av[i][0] || bv[i][2] != av[i][1] || +- bv[i][1] != av[i][2] || bv[i][0] != av[i][3]) +- return false; ++ DRM_DEV_DEBUG_DRIVER(dev, "V' all match!! %d, %d", retry, i); ++ return true; ++ } ++ } + +- DRM_DEV_DEBUG_DRIVER(dev, "V' all match!!"); +- return true; ++ DRM_DEV_DEBUG_DRIVER(dev, "V' NOT match!! %d", retry); ++ return false; + } + + static void it6505_hdcp_wait_ksv_list(struct work_struct *work) +-- +2.39.5 + diff --git a/queue-6.6/drm-bridge-it6505-fix-hdcp-cts-ksv-list-wait-timer.patch b/queue-6.6/drm-bridge-it6505-fix-hdcp-cts-ksv-list-wait-timer.patch new file mode 100644 index 0000000000..2b751cbe20 --- /dev/null +++ b/queue-6.6/drm-bridge-it6505-fix-hdcp-cts-ksv-list-wait-timer.patch @@ -0,0 +1,68 @@ +From 9a9b389f47358a27d3fb50b5d01807eac693a58b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 30 Dec 2024 18:51:27 +0800 +Subject: drm/bridge: it6505: fix HDCP CTS KSV list wait timer + +From: Hermes Wu + +[ Upstream commit 9f9eef9ec1a2b57d95a86fe81df758e8253a7766 ] + +HDCP must disabled encryption and restart authentication after +waiting KSV for 5s. +The original method uses a counter in a waitting loop that may +wait much longer than it is supposed to. +Use time_after() for KSV wait timeout. + +Signed-off-by: Hermes Wu +Reviewed-by: AngeloGioacchino Del Regno +Signed-off-by: Dmitry Baryshkov +Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-9-e0fdd4844703@ite.corp-partner.google.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/bridge/ite-it6505.c | 20 ++++++++++---------- + 1 file changed, 10 insertions(+), 10 deletions(-) + +diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c +index 552d33c4325af..fe33b988d7523 100644 +--- a/drivers/gpu/drm/bridge/ite-it6505.c ++++ b/drivers/gpu/drm/bridge/ite-it6505.c +@@ -2058,12 +2058,13 @@ static void it6505_hdcp_wait_ksv_list(struct work_struct *work) + struct it6505 *it6505 = container_of(work, struct it6505, + hdcp_wait_ksv_list); + struct device *dev = it6505->dev; +- unsigned int timeout = 5000; +- u8 bstatus = 0; ++ u8 bstatus; + bool ksv_list_check; ++ /* 1B-04 wait ksv list for 5s */ ++ unsigned long timeout = jiffies + ++ msecs_to_jiffies(5000) + 1; + +- timeout /= 20; +- while (timeout > 0) { ++ for (;;) { + if (!it6505_get_sink_hpd_status(it6505)) + return; + +@@ -2072,13 +2073,12 @@ static void it6505_hdcp_wait_ksv_list(struct work_struct *work) + if (bstatus & DP_BSTATUS_READY) + break; + +- msleep(20); +- timeout--; +- } ++ if (time_after(jiffies, timeout)) { ++ DRM_DEV_DEBUG_DRIVER(dev, "KSV list wait timeout"); ++ goto timeout; ++ } + +- if (timeout == 0) { +- DRM_DEV_DEBUG_DRIVER(dev, "timeout and ksv list wait failed"); +- goto timeout; ++ msleep(20); + } + + ksv_list_check = it6505_hdcp_part2_ksvlist_check(it6505); +-- +2.39.5 + diff --git a/queue-6.6/drm-bridge-it6505-fix-hdcp-encryption-when-r0-ready.patch b/queue-6.6/drm-bridge-it6505-fix-hdcp-encryption-when-r0-ready.patch new file mode 100644 index 0000000000..af18f0eb86 --- /dev/null +++ b/queue-6.6/drm-bridge-it6505-fix-hdcp-encryption-when-r0-ready.patch @@ -0,0 +1,65 @@ +From 222d053f75e96ddc52767eea48cebdcd37026f8b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 30 Dec 2024 18:51:24 +0800 +Subject: drm/bridge: it6505: fix HDCP encryption when R0 ready + +From: Hermes Wu + +[ Upstream commit 8c01b0bae2f9e58f2fee0e811cb90d8331986554 ] + +When starting HDCP authentication, HDCP encryption should be enabled +when R0'is checked. + +Change encryption enables time at R0' ready. +The hardware HDCP engine trigger is changed and the repeater KSV fails +will restart HDCP. + +Signed-off-by: Hermes Wu +Reviewed-by: AngeloGioacchino Del Regno +Signed-off-by: Dmitry Baryshkov +Link: https://patchwork.freedesktop.org/patch/msgid/20241230-v7-upstream-v7-6-e0fdd4844703@ite.corp-partner.google.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/bridge/ite-it6505.c | 17 +++++++++-------- + 1 file changed, 9 insertions(+), 8 deletions(-) + +diff --git a/drivers/gpu/drm/bridge/ite-it6505.c b/drivers/gpu/drm/bridge/ite-it6505.c +index f037288e841ac..f9f67e172eeee 100644 +--- a/drivers/gpu/drm/bridge/ite-it6505.c ++++ b/drivers/gpu/drm/bridge/ite-it6505.c +@@ -2078,15 +2078,12 @@ static void it6505_hdcp_wait_ksv_list(struct work_struct *work) + ksv_list_check = it6505_hdcp_part2_ksvlist_check(it6505); + DRM_DEV_DEBUG_DRIVER(dev, "ksv list ready, ksv list check %s", + ksv_list_check ? "pass" : "fail"); +- if (ksv_list_check) { +- it6505_set_bits(it6505, REG_HDCP_TRIGGER, +- HDCP_TRIGGER_KSV_DONE, HDCP_TRIGGER_KSV_DONE); ++ ++ if (ksv_list_check) + return; +- } ++ + timeout: +- it6505_set_bits(it6505, REG_HDCP_TRIGGER, +- HDCP_TRIGGER_KSV_DONE | HDCP_TRIGGER_KSV_FAIL, +- HDCP_TRIGGER_KSV_DONE | HDCP_TRIGGER_KSV_FAIL); ++ it6505_start_hdcp(it6505); + } + + static void it6505_hdcp_work(struct work_struct *work) +@@ -2459,7 +2456,11 @@ static void it6505_irq_hdcp_ksv_check(struct it6505 *it6505) + { + struct device *dev = it6505->dev; + +- DRM_DEV_DEBUG_DRIVER(dev, "HDCP event Interrupt"); ++ DRM_DEV_DEBUG_DRIVER(dev, "HDCP repeater R0 event Interrupt"); ++ /* 1B01 HDCP encription should start when R0 is ready*/ ++ it6505_set_bits(it6505, REG_HDCP_TRIGGER, ++ HDCP_TRIGGER_KSV_DONE, HDCP_TRIGGER_KSV_DONE); ++ + schedule_work(&it6505->hdcp_wait_ksv_list); + } + +-- +2.39.5 + diff --git a/queue-6.6/drm-bridge-ite-it66121-use-eld_mutex-to-protect-acce.patch b/queue-6.6/drm-bridge-ite-it66121-use-eld_mutex-to-protect-acce.patch new file mode 100644 index 0000000000..b299758946 --- /dev/null +++ b/queue-6.6/drm-bridge-ite-it66121-use-eld_mutex-to-protect-acce.patch @@ -0,0 +1,40 @@ +From eb6767598fcf7479d9b9fccb4edb3555c942ed48 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Dec 2024 11:43:06 +0200 +Subject: drm/bridge: ite-it66121: use eld_mutex to protect access to + connector->eld + +From: Dmitry Baryshkov + +[ Upstream commit 39ead6e02ea7d19b421e9d42299d4293fed3064e ] + +Reading access to connector->eld can happen at the same time the +drm_edid_to_eld() updates the data. Take the newly added eld_mutex in +order to protect connector->eld from concurrent access. + +Reviewed-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-3-c9bce1ee8bea@linaro.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/bridge/ite-it66121.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/gpu/drm/bridge/ite-it66121.c b/drivers/gpu/drm/bridge/ite-it66121.c +index 8f5846b76d594..2381cd1cba879 100644 +--- a/drivers/gpu/drm/bridge/ite-it66121.c ++++ b/drivers/gpu/drm/bridge/ite-it66121.c +@@ -1452,8 +1452,10 @@ static int it66121_audio_get_eld(struct device *dev, void *data, + dev_dbg(dev, "No connector present, passing empty EDID data"); + memset(buf, 0, len); + } else { ++ mutex_lock(&ctx->connector->eld_mutex); + memcpy(buf, ctx->connector->eld, + min(sizeof(ctx->connector->eld), len)); ++ mutex_unlock(&ctx->connector->eld_mutex); + } + mutex_unlock(&ctx->lock); + +-- +2.39.5 + diff --git a/queue-6.6/drm-connector-add-mutex-to-protect-eld-from-concurre.patch b/queue-6.6/drm-connector-add-mutex-to-protect-eld-from-concurre.patch new file mode 100644 index 0000000000..803208e011 --- /dev/null +++ b/queue-6.6/drm-connector-add-mutex-to-protect-eld-from-concurre.patch @@ -0,0 +1,90 @@ +From 9b14b6d9d91ed763ccd4b5131e56b34fbc105d45 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Dec 2024 11:43:04 +0200 +Subject: drm/connector: add mutex to protect ELD from concurrent access + +From: Dmitry Baryshkov + +[ Upstream commit df7c8e3dde37a9d81c0613285b43600f3cc70f34 ] + +The connector->eld is accessed by the .get_eld() callback. This access +can collide with the drm_edid_to_eld() updating the data at the same +time. Add drm_connector.eld_mutex to protect the data from concurrenct +access. Individual drivers are not updated (to reduce possible issues +while applying the patch), maintainers are to find a best suitable way +to lock that mutex while accessing the ELD data. + +Reviewed-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-1-c9bce1ee8bea@linaro.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/drm_connector.c | 1 + + drivers/gpu/drm/drm_edid.c | 6 ++++++ + include/drm/drm_connector.h | 5 ++++- + 3 files changed, 11 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c +index 309aad5f0c808..35bed66214474 100644 +--- a/drivers/gpu/drm/drm_connector.c ++++ b/drivers/gpu/drm/drm_connector.c +@@ -277,6 +277,7 @@ static int __drm_connector_init(struct drm_device *dev, + INIT_LIST_HEAD(&connector->probed_modes); + INIT_LIST_HEAD(&connector->modes); + mutex_init(&connector->mutex); ++ mutex_init(&connector->eld_mutex); + mutex_init(&connector->edid_override_mutex); + connector->edid_blob_ptr = NULL; + connector->epoch_counter = 0; +diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c +index ee3fab115c4b5..ad872c61aac0e 100644 +--- a/drivers/gpu/drm/drm_edid.c ++++ b/drivers/gpu/drm/drm_edid.c +@@ -5499,7 +5499,9 @@ EXPORT_SYMBOL(drm_edid_get_monitor_name); + + static void clear_eld(struct drm_connector *connector) + { ++ mutex_lock(&connector->eld_mutex); + memset(connector->eld, 0, sizeof(connector->eld)); ++ mutex_unlock(&connector->eld_mutex); + + connector->latency_present[0] = false; + connector->latency_present[1] = false; +@@ -5530,6 +5532,8 @@ static void drm_edid_to_eld(struct drm_connector *connector, + if (!drm_edid) + return; + ++ mutex_lock(&connector->eld_mutex); ++ + mnl = get_monitor_name(drm_edid, &eld[DRM_ELD_MONITOR_NAME_STRING]); + drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] ELD monitor %s\n", + connector->base.id, connector->name, +@@ -5590,6 +5594,8 @@ static void drm_edid_to_eld(struct drm_connector *connector, + drm_dbg_kms(connector->dev, "[CONNECTOR:%d:%s] ELD size %d, SAD count %d\n", + connector->base.id, connector->name, + drm_eld_size(eld), total_sad_count); ++ ++ mutex_unlock(&connector->eld_mutex); + } + + static int _drm_edid_to_sad(const struct drm_edid *drm_edid, +diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h +index d300fde6c1a47..b2e9dc02fa349 100644 +--- a/include/drm/drm_connector.h ++++ b/include/drm/drm_connector.h +@@ -1764,8 +1764,11 @@ struct drm_connector { + struct drm_encoder *encoder; + + #define MAX_ELD_BYTES 128 +- /** @eld: EDID-like data, if present */ ++ /** @eld: EDID-like data, if present, protected by @eld_mutex */ + uint8_t eld[MAX_ELD_BYTES]; ++ /** @eld_mutex: protection for concurrenct access to @eld */ ++ struct mutex eld_mutex; ++ + /** @latency_present: AV delay info from ELD, if found */ + bool latency_present[2]; + /** +-- +2.39.5 + diff --git a/queue-6.6/drm-exynos-hdmi-use-eld_mutex-to-protect-access-to-c.patch b/queue-6.6/drm-exynos-hdmi-use-eld_mutex-to-protect-access-to-c.patch new file mode 100644 index 0000000000..1ed6c86d64 --- /dev/null +++ b/queue-6.6/drm-exynos-hdmi-use-eld_mutex-to-protect-access-to-c.patch @@ -0,0 +1,38 @@ +From d413aacb7d713e09f86a2fec7d40af628622bf4f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Dec 2024 11:43:08 +0200 +Subject: drm/exynos: hdmi: use eld_mutex to protect access to connector->eld + +From: Dmitry Baryshkov + +[ Upstream commit 5e8436d334ed7f6785416447c50b42077c6503e0 ] + +Reading access to connector->eld can happen at the same time the +drm_edid_to_eld() updates the data. Take the newly added eld_mutex in +order to protect connector->eld from concurrent access. + +Reviewed-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-5-c9bce1ee8bea@linaro.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c +index 906133331a442..c234f9245b144 100644 +--- a/drivers/gpu/drm/exynos/exynos_hdmi.c ++++ b/drivers/gpu/drm/exynos/exynos_hdmi.c +@@ -1643,7 +1643,9 @@ static int hdmi_audio_get_eld(struct device *dev, void *data, uint8_t *buf, + struct hdmi_context *hdata = dev_get_drvdata(dev); + struct drm_connector *connector = &hdata->connector; + ++ mutex_lock(&connector->eld_mutex); + memcpy(buf, connector->eld, min(sizeof(connector->eld), len)); ++ mutex_unlock(&connector->eld_mutex); + + return 0; + } +-- +2.39.5 + diff --git a/queue-6.6/drm-radeon-use-eld_mutex-to-protect-access-to-connec.patch b/queue-6.6/drm-radeon-use-eld_mutex-to-protect-access-to-connec.patch new file mode 100644 index 0000000000..ca5de961bb --- /dev/null +++ b/queue-6.6/drm-radeon-use-eld_mutex-to-protect-access-to-connec.patch @@ -0,0 +1,39 @@ +From 6bb192e3c4cd63229e9af58775e31aa7c72e4139 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Dec 2024 11:43:11 +0200 +Subject: drm/radeon: use eld_mutex to protect access to connector->eld + +From: Dmitry Baryshkov + +[ Upstream commit b54c14f82428c8a602392d4cae1958a71a578132 ] + +Reading access to connector->eld can happen at the same time the +drm_edid_to_eld() updates the data. Take the newly added eld_mutex in +order to protect connector->eld from concurrent access. + +Reviewed-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-8-c9bce1ee8bea@linaro.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/radeon/radeon_audio.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/gpu/drm/radeon/radeon_audio.c b/drivers/gpu/drm/radeon/radeon_audio.c +index fc22fe709b9c1..da37a827337bc 100644 +--- a/drivers/gpu/drm/radeon/radeon_audio.c ++++ b/drivers/gpu/drm/radeon/radeon_audio.c +@@ -773,8 +773,10 @@ static int radeon_audio_component_get_eld(struct device *kdev, int port, + if (!dig->pin || dig->pin->id != port) + continue; + *enabled = true; ++ mutex_lock(&connector->eld_mutex); + ret = drm_eld_size(connector->eld); + memcpy(buf, connector->eld, min(max_bytes, ret)); ++ mutex_unlock(&connector->eld_mutex); + break; + } + +-- +2.39.5 + diff --git a/queue-6.6/drm-sti-hdmi-use-eld_mutex-to-protect-access-to-conn.patch b/queue-6.6/drm-sti-hdmi-use-eld_mutex-to-protect-access-to-conn.patch new file mode 100644 index 0000000000..6373e061c5 --- /dev/null +++ b/queue-6.6/drm-sti-hdmi-use-eld_mutex-to-protect-access-to-conn.patch @@ -0,0 +1,39 @@ +From baefa28a62fe4fa9a3efb3a8cf4ecadd7d23c2cd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Dec 2024 11:43:12 +0200 +Subject: drm/sti: hdmi: use eld_mutex to protect access to connector->eld + +From: Dmitry Baryshkov + +[ Upstream commit e99c0b517bcd53cf61f998a3c4291333401cb391 ] + +Reading access to connector->eld can happen at the same time the +drm_edid_to_eld() updates the data. Take the newly added eld_mutex in +order to protect connector->eld from concurrent access. + +Reviewed-by: Maxime Ripard +Acked-by: Raphael Gallais-Pou +Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-9-c9bce1ee8bea@linaro.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/sti/sti_hdmi.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c +index 500936d5743c5..90c68e0f493fb 100644 +--- a/drivers/gpu/drm/sti/sti_hdmi.c ++++ b/drivers/gpu/drm/sti/sti_hdmi.c +@@ -1221,7 +1221,9 @@ static int hdmi_audio_get_eld(struct device *dev, void *data, uint8_t *buf, size + struct drm_connector *connector = hdmi->drm_connector; + + DRM_DEBUG_DRIVER("\n"); ++ mutex_lock(&connector->eld_mutex); + memcpy(buf, connector->eld, min(sizeof(connector->eld), len)); ++ mutex_unlock(&connector->eld_mutex); + + return 0; + } +-- +2.39.5 + diff --git a/queue-6.6/drm-vc4-hdmi-use-eld_mutex-to-protect-access-to-conn.patch b/queue-6.6/drm-vc4-hdmi-use-eld_mutex-to-protect-access-to-conn.patch new file mode 100644 index 0000000000..19e3c6e98f --- /dev/null +++ b/queue-6.6/drm-vc4-hdmi-use-eld_mutex-to-protect-access-to-conn.patch @@ -0,0 +1,40 @@ +From 0ba4ddb295afdef7f5c2583bad49d65974db50b2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Dec 2024 11:43:13 +0200 +Subject: drm/vc4: hdmi: use eld_mutex to protect access to connector->eld + +From: Dmitry Baryshkov + +[ Upstream commit 81a9a93b169a273ccc4a9a1ee56f17e9981d3f98 ] + +Reading access to connector->eld can happen at the same time the +drm_edid_to_eld() updates the data. Take the newly added eld_mutex in +order to protect connector->eld from concurrent access. + +Reviewed-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-10-c9bce1ee8bea@linaro.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/vc4/vc4_hdmi.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c +index 1727d447786f1..541aba80c1449 100644 +--- a/drivers/gpu/drm/vc4/vc4_hdmi.c ++++ b/drivers/gpu/drm/vc4/vc4_hdmi.c +@@ -2655,9 +2655,9 @@ static int vc4_hdmi_audio_get_eld(struct device *dev, void *data, + struct vc4_hdmi *vc4_hdmi = dev_get_drvdata(dev); + struct drm_connector *connector = &vc4_hdmi->connector; + +- mutex_lock(&vc4_hdmi->mutex); ++ mutex_lock(&connector->eld_mutex); + memcpy(buf, connector->eld, min(sizeof(connector->eld), len)); +- mutex_unlock(&vc4_hdmi->mutex); ++ mutex_unlock(&connector->eld_mutex); + + return 0; + } +-- +2.39.5 + diff --git a/queue-6.6/drm-virtio-new-fence-for-every-plane-update.patch b/queue-6.6/drm-virtio-new-fence-for-every-plane-update.patch new file mode 100644 index 0000000000..caf41db65a --- /dev/null +++ b/queue-6.6/drm-virtio-new-fence-for-every-plane-update.patch @@ -0,0 +1,192 @@ +From 8e3ef6a8896821e7530cea33fda5bb931154e19a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 21 Oct 2024 02:08:03 +0300 +Subject: drm/virtio: New fence for every plane update + +From: Dongwon Kim + +[ Upstream commit d3c55b8ab6fe5fa2e7ab02efd36d09c39ee5022f ] + +Having a fence linked to a virtio_gpu_framebuffer in the plane update +sequence would cause conflict when several planes referencing the same +framebuffer (e.g. Xorg screen covering multi-displays configured for an +extended mode) and those planes are updated concurrently. So it is needed +to allocate a fence for every plane state instead of the framebuffer. + +Signed-off-by: Dongwon Kim +[dmitry.osipenko@collabora.com: rebase, fix up, edit commit message] +Signed-off-by: Dmitry Osipenko +Acked-by: Vivek Kasireddy +Reviewed-by: Rob Clark +Link: https://patchwork.freedesktop.org/patch/msgid/20241020230803.247419-2-dmitry.osipenko@collabora.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/virtio/virtgpu_drv.h | 7 ++++ + drivers/gpu/drm/virtio/virtgpu_plane.c | 58 +++++++++++++++++--------- + 2 files changed, 46 insertions(+), 19 deletions(-) + +diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h +index 4126c384286bf..61fd37f95fbd9 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_drv.h ++++ b/drivers/gpu/drm/virtio/virtgpu_drv.h +@@ -191,6 +191,13 @@ struct virtio_gpu_framebuffer { + #define to_virtio_gpu_framebuffer(x) \ + container_of(x, struct virtio_gpu_framebuffer, base) + ++struct virtio_gpu_plane_state { ++ struct drm_plane_state base; ++ struct virtio_gpu_fence *fence; ++}; ++#define to_virtio_gpu_plane_state(x) \ ++ container_of(x, struct virtio_gpu_plane_state, base) ++ + struct virtio_gpu_queue { + struct virtqueue *vq; + spinlock_t qlock; +diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c b/drivers/gpu/drm/virtio/virtgpu_plane.c +index a1ef657eba077..36de73e03bbfa 100644 +--- a/drivers/gpu/drm/virtio/virtgpu_plane.c ++++ b/drivers/gpu/drm/virtio/virtgpu_plane.c +@@ -66,11 +66,28 @@ uint32_t virtio_gpu_translate_format(uint32_t drm_fourcc) + return format; + } + ++static struct ++drm_plane_state *virtio_gpu_plane_duplicate_state(struct drm_plane *plane) ++{ ++ struct virtio_gpu_plane_state *new; ++ ++ if (WARN_ON(!plane->state)) ++ return NULL; ++ ++ new = kzalloc(sizeof(*new), GFP_KERNEL); ++ if (!new) ++ return NULL; ++ ++ __drm_atomic_helper_plane_duplicate_state(plane, &new->base); ++ ++ return &new->base; ++} ++ + static const struct drm_plane_funcs virtio_gpu_plane_funcs = { + .update_plane = drm_atomic_helper_update_plane, + .disable_plane = drm_atomic_helper_disable_plane, + .reset = drm_atomic_helper_plane_reset, +- .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state, ++ .atomic_duplicate_state = virtio_gpu_plane_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_plane_destroy_state, + }; + +@@ -138,11 +155,13 @@ static void virtio_gpu_resource_flush(struct drm_plane *plane, + struct drm_device *dev = plane->dev; + struct virtio_gpu_device *vgdev = dev->dev_private; + struct virtio_gpu_framebuffer *vgfb; ++ struct virtio_gpu_plane_state *vgplane_st; + struct virtio_gpu_object *bo; + + vgfb = to_virtio_gpu_framebuffer(plane->state->fb); ++ vgplane_st = to_virtio_gpu_plane_state(plane->state); + bo = gem_to_virtio_gpu_obj(vgfb->base.obj[0]); +- if (vgfb->fence) { ++ if (vgplane_st->fence) { + struct virtio_gpu_object_array *objs; + + objs = virtio_gpu_array_alloc(1); +@@ -151,13 +170,11 @@ static void virtio_gpu_resource_flush(struct drm_plane *plane, + virtio_gpu_array_add_obj(objs, vgfb->base.obj[0]); + virtio_gpu_array_lock_resv(objs); + virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle, x, y, +- width, height, objs, vgfb->fence); ++ width, height, objs, ++ vgplane_st->fence); + virtio_gpu_notify(vgdev); +- +- dma_fence_wait_timeout(&vgfb->fence->f, true, ++ dma_fence_wait_timeout(&vgplane_st->fence->f, true, + msecs_to_jiffies(50)); +- dma_fence_put(&vgfb->fence->f); +- vgfb->fence = NULL; + } else { + virtio_gpu_cmd_resource_flush(vgdev, bo->hw_res_handle, x, y, + width, height, NULL, NULL); +@@ -247,20 +264,23 @@ static int virtio_gpu_plane_prepare_fb(struct drm_plane *plane, + struct drm_device *dev = plane->dev; + struct virtio_gpu_device *vgdev = dev->dev_private; + struct virtio_gpu_framebuffer *vgfb; ++ struct virtio_gpu_plane_state *vgplane_st; + struct virtio_gpu_object *bo; + + if (!new_state->fb) + return 0; + + vgfb = to_virtio_gpu_framebuffer(new_state->fb); ++ vgplane_st = to_virtio_gpu_plane_state(new_state); + bo = gem_to_virtio_gpu_obj(vgfb->base.obj[0]); + if (!bo || (plane->type == DRM_PLANE_TYPE_PRIMARY && !bo->guest_blob)) + return 0; + +- if (bo->dumb && (plane->state->fb != new_state->fb)) { +- vgfb->fence = virtio_gpu_fence_alloc(vgdev, vgdev->fence_drv.context, ++ if (bo->dumb) { ++ vgplane_st->fence = virtio_gpu_fence_alloc(vgdev, ++ vgdev->fence_drv.context, + 0); +- if (!vgfb->fence) ++ if (!vgplane_st->fence) + return -ENOMEM; + } + +@@ -270,15 +290,15 @@ static int virtio_gpu_plane_prepare_fb(struct drm_plane *plane, + static void virtio_gpu_plane_cleanup_fb(struct drm_plane *plane, + struct drm_plane_state *state) + { +- struct virtio_gpu_framebuffer *vgfb; ++ struct virtio_gpu_plane_state *vgplane_st; + + if (!state->fb) + return; + +- vgfb = to_virtio_gpu_framebuffer(state->fb); +- if (vgfb->fence) { +- dma_fence_put(&vgfb->fence->f); +- vgfb->fence = NULL; ++ vgplane_st = to_virtio_gpu_plane_state(state); ++ if (vgplane_st->fence) { ++ dma_fence_put(&vgplane_st->fence->f); ++ vgplane_st->fence = NULL; + } + } + +@@ -291,6 +311,7 @@ static void virtio_gpu_cursor_plane_update(struct drm_plane *plane, + struct virtio_gpu_device *vgdev = dev->dev_private; + struct virtio_gpu_output *output = NULL; + struct virtio_gpu_framebuffer *vgfb; ++ struct virtio_gpu_plane_state *vgplane_st; + struct virtio_gpu_object *bo = NULL; + uint32_t handle; + +@@ -303,6 +324,7 @@ static void virtio_gpu_cursor_plane_update(struct drm_plane *plane, + + if (plane->state->fb) { + vgfb = to_virtio_gpu_framebuffer(plane->state->fb); ++ vgplane_st = to_virtio_gpu_plane_state(plane->state); + bo = gem_to_virtio_gpu_obj(vgfb->base.obj[0]); + handle = bo->hw_res_handle; + } else { +@@ -322,11 +344,9 @@ static void virtio_gpu_cursor_plane_update(struct drm_plane *plane, + (vgdev, 0, + plane->state->crtc_w, + plane->state->crtc_h, +- 0, 0, objs, vgfb->fence); ++ 0, 0, objs, vgplane_st->fence); + virtio_gpu_notify(vgdev); +- dma_fence_wait(&vgfb->fence->f, true); +- dma_fence_put(&vgfb->fence->f); +- vgfb->fence = NULL; ++ dma_fence_wait(&vgplane_st->fence->f, true); + } + + if (plane->state->fb != old_state->fb) { +-- +2.39.5 + diff --git a/queue-6.6/exec-fix-up-proc-pid-comm-in-the-execveat-at_empty_p.patch b/queue-6.6/exec-fix-up-proc-pid-comm-in-the-execveat-at_empty_p.patch new file mode 100644 index 0000000000..90efb6bc3e --- /dev/null +++ b/queue-6.6/exec-fix-up-proc-pid-comm-in-the-execveat-at_empty_p.patch @@ -0,0 +1,110 @@ +From 5e07b994a5a2416bd31bdd7445a1c47968bf793a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 21 Nov 2024 07:07:05 -0800 +Subject: exec: fix up /proc/pid/comm in the execveat(AT_EMPTY_PATH) case +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Kees Cook + +[ Upstream commit 543841d1806029889c2f69f040e88b247aba8e22 ] + +Zbigniew mentioned at Linux Plumber's that systemd is interested in +switching to execveat() for service execution, but can't, because the +contents of /proc/pid/comm are the file descriptor which was used, +instead of the path to the binary[1]. This makes the output of tools like +top and ps useless, especially in a world where most fds are opened +CLOEXEC so the number is truly meaningless. + +When the filename passed in is empty (e.g. with AT_EMPTY_PATH), use the +dentry's filename for "comm" instead of using the useless numeral from +the synthetic fdpath construction. This way the actual exec machinery +is unchanged, but cosmetically the comm looks reasonable to admins +investigating things. + +Instead of adding TASK_COMM_LEN more bytes to bprm, use one of the unused +flag bits to indicate that we need to set "comm" from the dentry. + +Suggested-by: Zbigniew Jędrzejewski-Szmek +Suggested-by: Tycho Andersen +Suggested-by: Al Viro +Suggested-by: Linus Torvalds +Link: https://github.com/uapi-group/kernel-features#set-comm-field-before-exec [1] +Reviewed-by: Aleksa Sarai +Tested-by: Zbigniew Jędrzejewski-Szmek +Signed-off-by: Kees Cook +Signed-off-by: Sasha Levin +--- + fs/exec.c | 29 ++++++++++++++++++++++++++--- + include/linux/binfmts.h | 4 +++- + 2 files changed, 29 insertions(+), 4 deletions(-) + +diff --git a/fs/exec.c b/fs/exec.c +index 7776209d98c10..4a6255aa4ea7f 100644 +--- a/fs/exec.c ++++ b/fs/exec.c +@@ -1362,7 +1362,28 @@ int begin_new_exec(struct linux_binprm * bprm) + set_dumpable(current->mm, SUID_DUMP_USER); + + perf_event_exec(); +- __set_task_comm(me, kbasename(bprm->filename), true); ++ ++ /* ++ * If the original filename was empty, alloc_bprm() made up a path ++ * that will probably not be useful to admins running ps or similar. ++ * Let's fix it up to be something reasonable. ++ */ ++ if (bprm->comm_from_dentry) { ++ /* ++ * Hold RCU lock to keep the name from being freed behind our back. ++ * Use acquire semantics to make sure the terminating NUL from ++ * __d_alloc() is seen. ++ * ++ * Note, we're deliberately sloppy here. We don't need to care about ++ * detecting a concurrent rename and just want a terminated name. ++ */ ++ rcu_read_lock(); ++ __set_task_comm(me, smp_load_acquire(&bprm->file->f_path.dentry->d_name.name), ++ true); ++ rcu_read_unlock(); ++ } else { ++ __set_task_comm(me, kbasename(bprm->filename), true); ++ } + + /* An exec changes our domain. We are no longer part of the thread + group */ +@@ -1521,11 +1542,13 @@ static struct linux_binprm *alloc_bprm(int fd, struct filename *filename) + if (fd == AT_FDCWD || filename->name[0] == '/') { + bprm->filename = filename->name; + } else { +- if (filename->name[0] == '\0') ++ if (filename->name[0] == '\0') { + bprm->fdpath = kasprintf(GFP_KERNEL, "/dev/fd/%d", fd); +- else ++ bprm->comm_from_dentry = 1; ++ } else { + bprm->fdpath = kasprintf(GFP_KERNEL, "/dev/fd/%d/%s", + fd, filename->name); ++ } + if (!bprm->fdpath) + goto out_free; + +diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h +index 8d51f69f9f5ef..af9056d78fadf 100644 +--- a/include/linux/binfmts.h ++++ b/include/linux/binfmts.h +@@ -42,7 +42,9 @@ struct linux_binprm { + * Set when errors can no longer be returned to the + * original userspace. + */ +- point_of_no_return:1; ++ point_of_no_return:1, ++ /* Set when "comm" must come from the dentry. */ ++ comm_from_dentry:1; + struct file *executable; /* Executable to pass to the interpreter */ + struct file *interpreter; + struct file *file; +-- +2.39.5 + diff --git a/queue-6.6/hid-wacom-add-pci-wacom-device-support.patch b/queue-6.6/hid-wacom-add-pci-wacom-device-support.patch new file mode 100644 index 0000000000..16dcf08bee --- /dev/null +++ b/queue-6.6/hid-wacom-add-pci-wacom-device-support.patch @@ -0,0 +1,46 @@ +From 55e916710b58e046ccbc9f2a93ac8a21df35cefd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Dec 2024 09:35:27 +0800 +Subject: HID: Wacom: Add PCI Wacom device support + +From: Even Xu + +[ Upstream commit c4c123504a65583e3689b3de04a61dc5272e453a ] + +Add PCI device ID of wacom device into driver support list. + +Signed-off-by: Even Xu +Tested-by: Tatsunosuke Tobita +Reviewed-by: Ping Cheng +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + drivers/hid/wacom_wac.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c +index 33466c71c9da7..dd44373ba930e 100644 +--- a/drivers/hid/wacom_wac.c ++++ b/drivers/hid/wacom_wac.c +@@ -4911,6 +4911,10 @@ static const struct wacom_features wacom_features_0x94 = + HID_DEVICE(BUS_I2C, HID_GROUP_WACOM, USB_VENDOR_ID_WACOM, prod),\ + .driver_data = (kernel_ulong_t)&wacom_features_##prod + ++#define PCI_DEVICE_WACOM(prod) \ ++ HID_DEVICE(BUS_PCI, HID_GROUP_WACOM, USB_VENDOR_ID_WACOM, prod),\ ++ .driver_data = (kernel_ulong_t)&wacom_features_##prod ++ + #define USB_DEVICE_LENOVO(prod) \ + HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, prod), \ + .driver_data = (kernel_ulong_t)&wacom_features_##prod +@@ -5080,6 +5084,7 @@ const struct hid_device_id wacom_ids[] = { + + { USB_DEVICE_WACOM(HID_ANY_ID) }, + { I2C_DEVICE_WACOM(HID_ANY_ID) }, ++ { PCI_DEVICE_WACOM(HID_ANY_ID) }, + { BT_DEVICE_WACOM(HID_ANY_ID) }, + { } + }; +-- +2.39.5 + diff --git a/queue-6.6/i2c-force-elan06fa-touchpad-i2c-bus-freq-to-100khz.patch b/queue-6.6/i2c-force-elan06fa-touchpad-i2c-bus-freq-to-100khz.patch new file mode 100644 index 0000000000..0adab4594b --- /dev/null +++ b/queue-6.6/i2c-force-elan06fa-touchpad-i2c-bus-freq-to-100khz.patch @@ -0,0 +1,73 @@ +From 6f13ba9c81aad02e50823b18a50de241211509f8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 Jan 2025 14:52:37 -0500 +Subject: i2c: Force ELAN06FA touchpad I2C bus freq to 100KHz + +From: Randolph Ha + +[ Upstream commit bfd74cd1fbc026f04446e67d6915c7e199c2bffd ] + +When a 400KHz freq is used on this model of ELAN touchpad in Linux, +excessive smoothing (similar to when the touchpad's firmware detects +a noisy signal) is sometimes applied. As some devices' (e.g, Lenovo +V15 G4) ACPI tables specify a 400KHz frequency for this device and +some I2C busses (e.g, Designware I2C) default to a 400KHz freq, +force the speed to 100KHz as a workaround. + +For future investigation: This problem may be related to the default +HCNT/LCNT values given by some busses' drivers, because they are not +specified in the aforementioned devices' ACPI tables, and because +the device works without issues on Windows at what is expected to be +a 400KHz frequency. The root cause of the issue is not known. + +Signed-off-by: Randolph Ha +Reviewed-by: Mika Westerberg +Signed-off-by: Wolfram Sang +Signed-off-by: Sasha Levin +--- + drivers/i2c/i2c-core-acpi.c | 22 ++++++++++++++++++++++ + 1 file changed, 22 insertions(+) + +diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c +index 14ae0cfc325ef..d2499f302b508 100644 +--- a/drivers/i2c/i2c-core-acpi.c ++++ b/drivers/i2c/i2c-core-acpi.c +@@ -355,6 +355,25 @@ static const struct acpi_device_id i2c_acpi_force_400khz_device_ids[] = { + {} + }; + ++static const struct acpi_device_id i2c_acpi_force_100khz_device_ids[] = { ++ /* ++ * When a 400KHz freq is used on this model of ELAN touchpad in Linux, ++ * excessive smoothing (similar to when the touchpad's firmware detects ++ * a noisy signal) is sometimes applied. As some devices' (e.g, Lenovo ++ * V15 G4) ACPI tables specify a 400KHz frequency for this device and ++ * some I2C busses (e.g, Designware I2C) default to a 400KHz freq, ++ * force the speed to 100KHz as a workaround. ++ * ++ * For future investigation: This problem may be related to the default ++ * HCNT/LCNT values given by some busses' drivers, because they are not ++ * specified in the aforementioned devices' ACPI tables, and because ++ * the device works without issues on Windows at what is expected to be ++ * a 400KHz frequency. The root cause of the issue is not known. ++ */ ++ { "ELAN06FA", 0 }, ++ {} ++}; ++ + static acpi_status i2c_acpi_lookup_speed(acpi_handle handle, u32 level, + void *data, void **return_value) + { +@@ -373,6 +392,9 @@ static acpi_status i2c_acpi_lookup_speed(acpi_handle handle, u32 level, + if (acpi_match_device_ids(adev, i2c_acpi_force_400khz_device_ids) == 0) + lookup->force_speed = I2C_MAX_FAST_MODE_FREQ; + ++ if (acpi_match_device_ids(adev, i2c_acpi_force_100khz_device_ids) == 0) ++ lookup->force_speed = I2C_MAX_STANDARD_MODE_FREQ; ++ + return AE_OK; + } + +-- +2.39.5 + diff --git a/queue-6.6/input-allocate-keycode-for-phone-linking.patch b/queue-6.6/input-allocate-keycode-for-phone-linking.patch new file mode 100644 index 0000000000..fcade98903 --- /dev/null +++ b/queue-6.6/input-allocate-keycode-for-phone-linking.patch @@ -0,0 +1,45 @@ +From ebebdd1b56561262abc4767098c6a0c4e3cbdcd7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 14 Nov 2024 18:39:29 +0100 +Subject: Input: allocate keycode for phone linking +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Illia Ostapyshyn + +[ Upstream commit 1bebc7869c99d466f819dd2cffaef0edf7d7a035 ] + +The F11 key on the new Lenovo Thinkpad T14 Gen 5, T16 Gen 3, and P14s +Gen 5 laptops includes a symbol showing a smartphone and a laptop +chained together. According to the user manual, it starts the Microsoft +Phone Link software used to connect to Android/iOS devices and relay +messages/calls or sync data. + +As there are no suitable keycodes for this action, introduce a new one. + +Signed-off-by: Illia Ostapyshyn +Acked-by: Dmitry Torokhov +Link: https://lore.kernel.org/r/20241114173930.44983-2-illia@yshyn.com +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Sasha Levin +--- + include/uapi/linux/input-event-codes.h | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h +index a4206723f5033..5a199f3d4a26a 100644 +--- a/include/uapi/linux/input-event-codes.h ++++ b/include/uapi/linux/input-event-codes.h +@@ -519,6 +519,7 @@ + #define KEY_NOTIFICATION_CENTER 0x1bc /* Show/hide the notification center */ + #define KEY_PICKUP_PHONE 0x1bd /* Answer incoming call */ + #define KEY_HANGUP_PHONE 0x1be /* Decline incoming call */ ++#define KEY_LINK_PHONE 0x1bf /* AL Phone Syncing */ + + #define KEY_DEL_EOL 0x1c0 + #define KEY_DEL_EOS 0x1c1 +-- +2.39.5 + diff --git a/queue-6.6/iommu-arm-smmu-qcom-add-sdm670-adreno-iommu-compatib.patch b/queue-6.6/iommu-arm-smmu-qcom-add-sdm670-adreno-iommu-compatib.patch new file mode 100644 index 0000000000..f4ec7a51b8 --- /dev/null +++ b/queue-6.6/iommu-arm-smmu-qcom-add-sdm670-adreno-iommu-compatib.patch @@ -0,0 +1,46 @@ +From 5a350c1e84ff183bc288895684a738f416710f94 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 13 Nov 2024 19:47:16 -0500 +Subject: iommu/arm-smmu-qcom: add sdm670 adreno iommu compatible + +From: Richard Acayan + +[ Upstream commit 42314738906380cbd3b6e9caf3ad34e1b2d66035 ] + +Add the compatible for the separate IOMMU on SDM670 for the Adreno GPU. + +This IOMMU has the compatible strings: + + "qcom,sdm670-smmu-v2", "qcom,adreno-smmu", "qcom,smmu-v2" + +While the SMMU 500 doesn't need an entry for this specific SoC, the +SMMU v2 compatible should have its own entry, as the fallback entry in +arm-smmu.c handles "qcom,smmu-v2" without per-process page table support +unless there is an entry here. This entry can't be the +"qcom,adreno-smmu" compatible because dedicated GPU IOMMUs can also be +SMMU 500 with different handling. + +Signed-off-by: Richard Acayan +Reviewed-by: Dmitry Baryshkov +Link: https://lore.kernel.org/r/20241114004713.42404-6-mailingradian@gmail.com +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c +index d491589360197..e6b4bab0dde2e 100644 +--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c ++++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c +@@ -554,6 +554,7 @@ static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = { + { .compatible = "qcom,sc8180x-smmu-500", .data = &qcom_smmu_500_impl0_data }, + { .compatible = "qcom,sc8280xp-smmu-500", .data = &qcom_smmu_500_impl0_data }, + { .compatible = "qcom,sdm630-smmu-v2", .data = &qcom_smmu_v2_data }, ++ { .compatible = "qcom,sdm670-smmu-v2", .data = &qcom_smmu_v2_data }, + { .compatible = "qcom,sdm845-smmu-v2", .data = &qcom_smmu_v2_data }, + { .compatible = "qcom,sdm845-smmu-500", .data = &sdm845_smmu_500_data }, + { .compatible = "qcom,sm6115-smmu-500", .data = &qcom_smmu_500_impl0_data}, +-- +2.39.5 + diff --git a/queue-6.6/iommu-arm-smmu-v3-clean-up-more-on-probe-failure.patch b/queue-6.6/iommu-arm-smmu-v3-clean-up-more-on-probe-failure.patch new file mode 100644 index 0000000000..b7d55f76f1 --- /dev/null +++ b/queue-6.6/iommu-arm-smmu-v3-clean-up-more-on-probe-failure.patch @@ -0,0 +1,75 @@ +From 7b169e1cc114e346aeb4ce8f0444c4877a5e69fe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 5 Dec 2024 16:33:57 +0000 +Subject: iommu/arm-smmu-v3: Clean up more on probe failure + +From: Robin Murphy + +[ Upstream commit fcbd621567420b3a2f21f49bbc056de8b273c625 ] + +kmemleak noticed that the iopf queue allocated deep down within +arm_smmu_init_structures() can be leaked by a subsequent error return +from arm_smmu_device_probe(). Furthermore, after arm_smmu_device_reset() +we will also leave the SMMU enabled with an empty Stream Table, silently +blocking all DMA. This proves rather annoying for debugging said probe +failure, so let's handle it a bit better by putting the SMMU back into +(more or less) the same state as if it hadn't probed at all. + +Signed-off-by: Robin Murphy +Link: https://lore.kernel.org/r/5137901958471cf67f2fad5c2229f8a8f1ae901a.1733406914.git.robin.murphy@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 17 ++++++++++++----- + 1 file changed, 12 insertions(+), 5 deletions(-) + +diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +index 68b81f9c2f4b1..6cecbac0e6bab 100644 +--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c ++++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c +@@ -3875,7 +3875,7 @@ static int arm_smmu_device_probe(struct platform_device *pdev) + /* Initialise in-memory data structures */ + ret = arm_smmu_init_structures(smmu); + if (ret) +- return ret; ++ goto err_free_iopf; + + /* Record our private device structure */ + platform_set_drvdata(pdev, smmu); +@@ -3886,22 +3886,29 @@ static int arm_smmu_device_probe(struct platform_device *pdev) + /* Reset the device */ + ret = arm_smmu_device_reset(smmu, bypass); + if (ret) +- return ret; ++ goto err_disable; + + /* And we're up. Go go go! */ + ret = iommu_device_sysfs_add(&smmu->iommu, dev, NULL, + "smmu3.%pa", &ioaddr); + if (ret) +- return ret; ++ goto err_disable; + + ret = iommu_device_register(&smmu->iommu, &arm_smmu_ops, dev); + if (ret) { + dev_err(dev, "Failed to register iommu\n"); +- iommu_device_sysfs_remove(&smmu->iommu); +- return ret; ++ goto err_free_sysfs; + } + + return 0; ++ ++err_free_sysfs: ++ iommu_device_sysfs_remove(&smmu->iommu); ++err_disable: ++ arm_smmu_device_disable(smmu); ++err_free_iopf: ++ iopf_queue_free(smmu->evtq.iopf); ++ return ret; + } + + static void arm_smmu_device_remove(struct platform_device *pdev) +-- +2.39.5 + diff --git a/queue-6.6/kvm-e500-always-restore-irqs.patch b/queue-6.6/kvm-e500-always-restore-irqs.patch new file mode 100644 index 0000000000..ee40d17108 --- /dev/null +++ b/queue-6.6/kvm-e500-always-restore-irqs.patch @@ -0,0 +1,47 @@ +From 38b35c8c8dfc426ece64ffbf149a026aa2acd70c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 12 Jan 2025 10:34:44 +0100 +Subject: KVM: e500: always restore irqs + +From: Paolo Bonzini + +[ Upstream commit 87ecfdbc699cc95fac73291b52650283ddcf929d ] + +If find_linux_pte fails, IRQs will not be restored. This is unlikely +to happen in practice since it would have been reported as hanging +hosts, but it should of course be fixed anyway. + +Cc: stable@vger.kernel.org +Reported-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Sasha Levin +--- + arch/powerpc/kvm/e500_mmu_host.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c +index 1910a48679e52..bd413dafbaf96 100644 +--- a/arch/powerpc/kvm/e500_mmu_host.c ++++ b/arch/powerpc/kvm/e500_mmu_host.c +@@ -479,7 +479,6 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, + if (pte_present(pte)) { + wimg = (pte_val(pte) >> PTE_WIMGE_SHIFT) & + MAS2_WIMGE_MASK; +- local_irq_restore(flags); + } else { + local_irq_restore(flags); + pr_err_ratelimited("%s: pte not present: gfn %lx,pfn %lx\n", +@@ -488,8 +487,9 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, + goto out; + } + } +- writable = kvmppc_e500_ref_setup(ref, gtlbe, pfn, wimg); ++ local_irq_restore(flags); + ++ writable = kvmppc_e500_ref_setup(ref, gtlbe, pfn, wimg); + kvmppc_e500_setup_stlbe(&vcpu_e500->vcpu, gtlbe, tsize, + ref, gvaddr, stlbe); + +-- +2.39.5 + diff --git a/queue-6.6/kvm-ppc-e500-mark-struct-page-dirty-in-kvmppc_e500_s.patch b/queue-6.6/kvm-ppc-e500-mark-struct-page-dirty-in-kvmppc_e500_s.patch new file mode 100644 index 0000000000..532087473d --- /dev/null +++ b/queue-6.6/kvm-ppc-e500-mark-struct-page-dirty-in-kvmppc_e500_s.patch @@ -0,0 +1,75 @@ +From d787735948fee0e9f79e9ead356bf3287e66a0ba Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 10 Oct 2024 11:23:54 -0700 +Subject: KVM: PPC: e500: Mark "struct page" dirty in kvmppc_e500_shadow_map() + +From: Sean Christopherson + +[ Upstream commit c9be85dabb376299504e0d391d15662c0edf8273 ] + +Mark the underlying page as dirty in kvmppc_e500_ref_setup()'s sole +caller, kvmppc_e500_shadow_map(), which will allow converting e500 to +__kvm_faultin_pfn() + kvm_release_faultin_page() without having to do +a weird dance between ref_setup() and shadow_map(). + +Opportunistically drop the redundant kvm_set_pfn_accessed(), as +shadow_map() puts the page via kvm_release_pfn_clean(). + +Signed-off-by: Sean Christopherson +Tested-by: Dmitry Osipenko +Signed-off-by: Paolo Bonzini +Message-ID: <20241010182427.1434605-53-seanjc@google.com> +Stable-dep-of: 87ecfdbc699c ("KVM: e500: always restore irqs") +Signed-off-by: Sasha Levin +--- + arch/powerpc/kvm/e500_mmu_host.c | 13 ++++++------- + 1 file changed, 6 insertions(+), 7 deletions(-) + +diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c +index ccb8f16ffe412..79c6359b18ae3 100644 +--- a/arch/powerpc/kvm/e500_mmu_host.c ++++ b/arch/powerpc/kvm/e500_mmu_host.c +@@ -242,7 +242,7 @@ static inline int tlbe_is_writable(struct kvm_book3e_206_tlb_entry *tlbe) + return tlbe->mas7_3 & (MAS3_SW|MAS3_UW); + } + +-static inline void kvmppc_e500_ref_setup(struct tlbe_ref *ref, ++static inline bool kvmppc_e500_ref_setup(struct tlbe_ref *ref, + struct kvm_book3e_206_tlb_entry *gtlbe, + kvm_pfn_t pfn, unsigned int wimg) + { +@@ -252,11 +252,7 @@ static inline void kvmppc_e500_ref_setup(struct tlbe_ref *ref, + /* Use guest supplied MAS2_G and MAS2_E */ + ref->flags |= (gtlbe->mas2 & MAS2_ATTRIB_MASK) | wimg; + +- /* Mark the page accessed */ +- kvm_set_pfn_accessed(pfn); +- +- if (tlbe_is_writable(gtlbe)) +- kvm_set_pfn_dirty(pfn); ++ return tlbe_is_writable(gtlbe); + } + + static inline void kvmppc_e500_ref_release(struct tlbe_ref *ref) +@@ -337,6 +333,7 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, + unsigned int wimg = 0; + pgd_t *pgdir; + unsigned long flags; ++ bool writable = false; + + /* used to check for invalidations in progress */ + mmu_seq = kvm->mmu_invalidate_seq; +@@ -490,7 +487,9 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, + goto out; + } + } +- kvmppc_e500_ref_setup(ref, gtlbe, pfn, wimg); ++ writable = kvmppc_e500_ref_setup(ref, gtlbe, pfn, wimg); ++ if (writable) ++ kvm_set_pfn_dirty(pfn); + + kvmppc_e500_setup_stlbe(&vcpu_e500->vcpu, gtlbe, tsize, + ref, gvaddr, stlbe); +-- +2.39.5 + diff --git a/queue-6.6/kvm-ppc-e500-mark-struct-page-pfn-accessed-before-dr.patch b/queue-6.6/kvm-ppc-e500-mark-struct-page-pfn-accessed-before-dr.patch new file mode 100644 index 0000000000..3396b3c4df --- /dev/null +++ b/queue-6.6/kvm-ppc-e500-mark-struct-page-pfn-accessed-before-dr.patch @@ -0,0 +1,46 @@ +From b3cd093f271e532eff4106e2c9e3950333bb43e6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 10 Oct 2024 11:23:55 -0700 +Subject: KVM: PPC: e500: Mark "struct page" pfn accessed before dropping + mmu_lock + +From: Sean Christopherson + +[ Upstream commit 84cf78dcd9d65c45ab73998d4ad50f433d53fb93 ] + +Mark pages accessed before dropping mmu_lock when faulting in guest memory +so that shadow_map() can convert to kvm_release_faultin_page() without +tripping its lockdep assertion on mmu_lock being held. Marking pages +accessed outside of mmu_lock is ok (not great, but safe), but marking +pages _dirty_ outside of mmu_lock can make filesystems unhappy. + +Signed-off-by: Sean Christopherson +Tested-by: Dmitry Osipenko +Signed-off-by: Paolo Bonzini +Message-ID: <20241010182427.1434605-54-seanjc@google.com> +Stable-dep-of: 87ecfdbc699c ("KVM: e500: always restore irqs") +Signed-off-by: Sasha Levin +--- + arch/powerpc/kvm/e500_mmu_host.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c +index 79c6359b18ae3..dc75f025dfe27 100644 +--- a/arch/powerpc/kvm/e500_mmu_host.c ++++ b/arch/powerpc/kvm/e500_mmu_host.c +@@ -498,11 +498,9 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, + kvmppc_mmu_flush_icache(pfn); + + out: +- spin_unlock(&kvm->mmu_lock); +- + /* Drop refcount on page, so that mmu notifiers can clear it */ + kvm_release_pfn_clean(pfn); +- ++ spin_unlock(&kvm->mmu_lock); + return ret; + } + +-- +2.39.5 + diff --git a/queue-6.6/kvm-ppc-e500-use-__kvm_faultin_pfn-to-handle-page-fa.patch b/queue-6.6/kvm-ppc-e500-use-__kvm_faultin_pfn-to-handle-page-fa.patch new file mode 100644 index 0000000000..f3d363181d --- /dev/null +++ b/queue-6.6/kvm-ppc-e500-use-__kvm_faultin_pfn-to-handle-page-fa.patch @@ -0,0 +1,66 @@ +From a7a4aaeeacc99db5af7213a7530a6b28375dba62 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 10 Oct 2024 11:23:56 -0700 +Subject: KVM: PPC: e500: Use __kvm_faultin_pfn() to handle page faults + +From: Sean Christopherson + +[ Upstream commit 419cfb983ca93e75e905794521afefcfa07988bb ] + +Convert PPC e500 to use __kvm_faultin_pfn()+kvm_release_faultin_page(), +and continue the inexorable march towards the demise of +kvm_pfn_to_refcounted_page(). + +Signed-off-by: Sean Christopherson +Tested-by: Dmitry Osipenko +Signed-off-by: Paolo Bonzini +Message-ID: <20241010182427.1434605-55-seanjc@google.com> +Stable-dep-of: 87ecfdbc699c ("KVM: e500: always restore irqs") +Signed-off-by: Sasha Levin +--- + arch/powerpc/kvm/e500_mmu_host.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c +index dc75f025dfe27..1910a48679e52 100644 +--- a/arch/powerpc/kvm/e500_mmu_host.c ++++ b/arch/powerpc/kvm/e500_mmu_host.c +@@ -322,6 +322,7 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, + { + struct kvm_memory_slot *slot; + unsigned long pfn = 0; /* silence GCC warning */ ++ struct page *page = NULL; + unsigned long hva; + int pfnmap = 0; + int tsize = BOOK3E_PAGESZ_4K; +@@ -443,7 +444,7 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, + + if (likely(!pfnmap)) { + tsize_pages = 1UL << (tsize + 10 - PAGE_SHIFT); +- pfn = gfn_to_pfn_memslot(slot, gfn); ++ pfn = __kvm_faultin_pfn(slot, gfn, FOLL_WRITE, NULL, &page); + if (is_error_noslot_pfn(pfn)) { + if (printk_ratelimit()) + pr_err("%s: real page not found for gfn %lx\n", +@@ -488,8 +489,6 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, + } + } + writable = kvmppc_e500_ref_setup(ref, gtlbe, pfn, wimg); +- if (writable) +- kvm_set_pfn_dirty(pfn); + + kvmppc_e500_setup_stlbe(&vcpu_e500->vcpu, gtlbe, tsize, + ref, gvaddr, stlbe); +@@ -498,8 +497,7 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500, + kvmppc_mmu_flush_icache(pfn); + + out: +- /* Drop refcount on page, so that mmu notifiers can clear it */ +- kvm_release_pfn_clean(pfn); ++ kvm_release_faultin_page(kvm, page, !!ret, writable); + spin_unlock(&kvm->mmu_lock); + return ret; + } +-- +2.39.5 + diff --git a/queue-6.6/lockdep-fix-upper-limit-for-lockdep_-_bits-configs.patch b/queue-6.6/lockdep-fix-upper-limit-for-lockdep_-_bits-configs.patch new file mode 100644 index 0000000000..575051a07e --- /dev/null +++ b/queue-6.6/lockdep-fix-upper-limit-for-lockdep_-_bits-configs.patch @@ -0,0 +1,86 @@ +From 2ecbacb5944ef9500fd0f5c63ef485823f539409 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 24 Oct 2024 18:36:26 +0000 +Subject: lockdep: Fix upper limit for LOCKDEP_*_BITS configs + +From: Carlos Llamas + +[ Upstream commit e638072e61726cae363d48812815197a2a0e097f ] + +Lockdep has a set of configs used to determine the size of the static +arrays that it uses. However, the upper limit that was initially setup +for these configs is too high (30 bit shift). This equates to several +GiB of static memory for individual symbols. Using such high values +leads to linker errors: + + $ make defconfig + $ ./scripts/config -e PROVE_LOCKING --set-val LOCKDEP_BITS 30 + $ make olddefconfig all + [...] + ld: kernel image bigger than KERNEL_IMAGE_SIZE + ld: section .bss VMA wraps around address space + +Adjust the upper limits to the maximum values that avoid these issues. +The need for anything more, likely points to a problem elsewhere. Note +that LOCKDEP_CHAINS_BITS was intentionally left out as its upper limit +had a different symptom and has already been fixed [1]. + +Reported-by: J. R. Okajima +Closes: https://lore.kernel.org/all/30795.1620913191@jrobl/ [1] +Cc: Peter Zijlstra +Cc: Boqun Feng +Cc: Ingo Molnar +Cc: Waiman Long +Cc: Will Deacon +Acked-by: Waiman Long +Signed-off-by: Carlos Llamas +Signed-off-by: Boqun Feng +Link: https://lore.kernel.org/r/20241024183631.643450-2-cmllamas@google.com +Signed-off-by: Sasha Levin +--- + lib/Kconfig.debug | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug +index f94c3e957b829..e809b6d8bc537 100644 +--- a/lib/Kconfig.debug ++++ b/lib/Kconfig.debug +@@ -1454,7 +1454,7 @@ config LOCKDEP_SMALL + config LOCKDEP_BITS + int "Bitsize for MAX_LOCKDEP_ENTRIES" + depends on LOCKDEP && !LOCKDEP_SMALL +- range 10 30 ++ range 10 24 + default 15 + help + Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message. +@@ -1470,7 +1470,7 @@ config LOCKDEP_CHAINS_BITS + config LOCKDEP_STACK_TRACE_BITS + int "Bitsize for MAX_STACK_TRACE_ENTRIES" + depends on LOCKDEP && !LOCKDEP_SMALL +- range 10 30 ++ range 10 26 + default 19 + help + Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message. +@@ -1478,7 +1478,7 @@ config LOCKDEP_STACK_TRACE_BITS + config LOCKDEP_STACK_TRACE_HASH_BITS + int "Bitsize for STACK_TRACE_HASH_SIZE" + depends on LOCKDEP && !LOCKDEP_SMALL +- range 10 30 ++ range 10 26 + default 14 + help + Try increasing this value if you need large STACK_TRACE_HASH_SIZE. +@@ -1486,7 +1486,7 @@ config LOCKDEP_STACK_TRACE_HASH_BITS + config LOCKDEP_CIRCULAR_QUEUE_BITS + int "Bitsize for elements in circular_queue struct" + depends on LOCKDEP +- range 10 30 ++ range 10 26 + default 12 + help + Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure. +-- +2.39.5 + diff --git a/queue-6.6/mfd-lpc_ich-add-another-gemini-lake-isa-bridge-pci-d.patch b/queue-6.6/mfd-lpc_ich-add-another-gemini-lake-isa-bridge-pci-d.patch new file mode 100644 index 0000000000..e0e45017ce --- /dev/null +++ b/queue-6.6/mfd-lpc_ich-add-another-gemini-lake-isa-bridge-pci-d.patch @@ -0,0 +1,42 @@ +From 1e8facbc030bd9ca2e5423d0fcebf39def875329 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 14 Nov 2024 20:38:08 +0100 +Subject: mfd: lpc_ich: Add another Gemini Lake ISA bridge PCI device-id + +From: Hans de Goede + +[ Upstream commit 1e89d21f8189d286f80b900e1b7cf57cb1f3037e ] + +On N4100 / N4120 Gemini Lake SoCs the ISA bridge PCI device-id is 31e8 +rather the 3197 found on e.g. the N4000 / N4020. + +While at fix the existing GLK PCI-id table entry breaking the table +being sorted by device-id. + +Signed-off-by: Hans de Goede +Reviewed-by: Andy Shevchenko +Link: https://lore.kernel.org/r/20241114193808.110132-1-hdegoede@redhat.com +Signed-off-by: Lee Jones +Signed-off-by: Sasha Levin +--- + drivers/mfd/lpc_ich.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c +index 7b1c597b6879f..03367fcac42a7 100644 +--- a/drivers/mfd/lpc_ich.c ++++ b/drivers/mfd/lpc_ich.c +@@ -756,8 +756,9 @@ static const struct pci_device_id lpc_ich_ids[] = { + { PCI_VDEVICE(INTEL, 0x2917), LPC_ICH9ME}, + { PCI_VDEVICE(INTEL, 0x2918), LPC_ICH9}, + { PCI_VDEVICE(INTEL, 0x2919), LPC_ICH9M}, +- { PCI_VDEVICE(INTEL, 0x3197), LPC_GLK}, + { PCI_VDEVICE(INTEL, 0x2b9c), LPC_COUGARMOUNTAIN}, ++ { PCI_VDEVICE(INTEL, 0x3197), LPC_GLK}, ++ { PCI_VDEVICE(INTEL, 0x31e8), LPC_GLK}, + { PCI_VDEVICE(INTEL, 0x3a14), LPC_ICH10DO}, + { PCI_VDEVICE(INTEL, 0x3a16), LPC_ICH10R}, + { PCI_VDEVICE(INTEL, 0x3a18), LPC_ICH10}, +-- +2.39.5 + diff --git a/queue-6.6/mmc-core-respect-quirk_max_rate-for-non-uhs-sdio-car.patch b/queue-6.6/mmc-core-respect-quirk_max_rate-for-non-uhs-sdio-car.patch new file mode 100644 index 0000000000..e84d5b2452 --- /dev/null +++ b/queue-6.6/mmc-core-respect-quirk_max_rate-for-non-uhs-sdio-car.patch @@ -0,0 +1,37 @@ +From 6b34ca35e6f4927c95f14a0aff292593879379c4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 22 Nov 2024 17:37:22 +0800 +Subject: mmc: core: Respect quirk_max_rate for non-UHS SDIO card + +From: Shawn Lin + +[ Upstream commit a2a44f8da29352f76c99c6904ee652911b8dc7dd ] + +The card-quirk was added to limit the clock-rate for a card with UHS-mode +support, although let's respect the quirk for non-UHS mode too, to make the +behaviour consistent. + +Signed-off-by: Shawn Lin +Message-ID: <1732268242-72799-1-git-send-email-shawn.lin@rock-chips.com> +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/core/sdio.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c +index 5914516df2f7f..cb87e82737793 100644 +--- a/drivers/mmc/core/sdio.c ++++ b/drivers/mmc/core/sdio.c +@@ -458,6 +458,8 @@ static unsigned mmc_sdio_get_max_clock(struct mmc_card *card) + if (mmc_card_sd_combo(card)) + max_dtr = min(max_dtr, mmc_sd_get_max_clock(card)); + ++ max_dtr = min_not_zero(max_dtr, card->quirk_max_rate); ++ + return max_dtr; + } + +-- +2.39.5 + diff --git a/queue-6.6/mmc-sdhci-msm-correctly-set-the-load-for-the-regulat.patch b/queue-6.6/mmc-sdhci-msm-correctly-set-the-load-for-the-regulat.patch new file mode 100644 index 0000000000..af03efd9e0 --- /dev/null +++ b/queue-6.6/mmc-sdhci-msm-correctly-set-the-load-for-the-regulat.patch @@ -0,0 +1,122 @@ +From 2a8ba894abb9bbb89fe98d5098bff416b2b61c11 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 14 Jan 2025 16:35:14 +0800 +Subject: mmc: sdhci-msm: Correctly set the load for the regulator + +From: Yuanjie Yang + +[ Upstream commit 20a0c37e44063997391430c4ae09973e9cbc3911 ] + +Qualcomm regulator supports two power supply modes: HPM and LPM. +Currently, the sdhci-msm.c driver does not set the load to adjust +the current for eMMC and SD. If the regulator dont't set correct +load in LPM state, it will lead to the inability to properly +initialize eMMC and SD. + +Set the correct regulator current for eMMC and SD to ensure that the +device can work normally even when the regulator is in LPM. + +Signed-off-by: Yuanjie Yang +Reviewed-by: Dmitry Baryshkov +Link: https://lore.kernel.org/r/20250114083514.258379-1-quic_yuanjiey@quicinc.com +Signed-off-by: Ulf Hansson +Signed-off-by: Sasha Levin +--- + drivers/mmc/host/sdhci-msm.c | 53 ++++++++++++++++++++++++++++++++++-- + 1 file changed, 51 insertions(+), 2 deletions(-) + +diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c +index 8716004fcf6c9..945d08531de37 100644 +--- a/drivers/mmc/host/sdhci-msm.c ++++ b/drivers/mmc/host/sdhci-msm.c +@@ -134,9 +134,18 @@ + /* Timeout value to avoid infinite waiting for pwr_irq */ + #define MSM_PWR_IRQ_TIMEOUT_MS 5000 + ++/* Max load for eMMC Vdd supply */ ++#define MMC_VMMC_MAX_LOAD_UA 570000 ++ + /* Max load for eMMC Vdd-io supply */ + #define MMC_VQMMC_MAX_LOAD_UA 325000 + ++/* Max load for SD Vdd supply */ ++#define SD_VMMC_MAX_LOAD_UA 800000 ++ ++/* Max load for SD Vdd-io supply */ ++#define SD_VQMMC_MAX_LOAD_UA 22000 ++ + #define msm_host_readl(msm_host, host, offset) \ + msm_host->var_ops->msm_readl_relaxed(host, offset) + +@@ -1403,11 +1412,48 @@ static int sdhci_msm_set_pincfg(struct sdhci_msm_host *msm_host, bool level) + return ret; + } + +-static int sdhci_msm_set_vmmc(struct mmc_host *mmc) ++static void msm_config_vmmc_regulator(struct mmc_host *mmc, bool hpm) ++{ ++ int load; ++ ++ if (!hpm) ++ load = 0; ++ else if (!mmc->card) ++ load = max(MMC_VMMC_MAX_LOAD_UA, SD_VMMC_MAX_LOAD_UA); ++ else if (mmc_card_mmc(mmc->card)) ++ load = MMC_VMMC_MAX_LOAD_UA; ++ else if (mmc_card_sd(mmc->card)) ++ load = SD_VMMC_MAX_LOAD_UA; ++ else ++ return; ++ ++ regulator_set_load(mmc->supply.vmmc, load); ++} ++ ++static void msm_config_vqmmc_regulator(struct mmc_host *mmc, bool hpm) ++{ ++ int load; ++ ++ if (!hpm) ++ load = 0; ++ else if (!mmc->card) ++ load = max(MMC_VQMMC_MAX_LOAD_UA, SD_VQMMC_MAX_LOAD_UA); ++ else if (mmc_card_sd(mmc->card)) ++ load = SD_VQMMC_MAX_LOAD_UA; ++ else ++ return; ++ ++ regulator_set_load(mmc->supply.vqmmc, load); ++} ++ ++static int sdhci_msm_set_vmmc(struct sdhci_msm_host *msm_host, ++ struct mmc_host *mmc, bool hpm) + { + if (IS_ERR(mmc->supply.vmmc)) + return 0; + ++ msm_config_vmmc_regulator(mmc, hpm); ++ + return mmc_regulator_set_ocr(mmc, mmc->supply.vmmc, mmc->ios.vdd); + } + +@@ -1420,6 +1466,8 @@ static int msm_toggle_vqmmc(struct sdhci_msm_host *msm_host, + if (msm_host->vqmmc_enabled == level) + return 0; + ++ msm_config_vqmmc_regulator(mmc, level); ++ + if (level) { + /* Set the IO voltage regulator to default voltage level */ + if (msm_host->caps_0 & CORE_3_0V_SUPPORT) +@@ -1642,7 +1690,8 @@ static void sdhci_msm_handle_pwr_irq(struct sdhci_host *host, int irq) + } + + if (pwr_state) { +- ret = sdhci_msm_set_vmmc(mmc); ++ ret = sdhci_msm_set_vmmc(msm_host, mmc, ++ pwr_state & REQ_BUS_ON); + if (!ret) + ret = sdhci_msm_set_vqmmc(msm_host, mmc, + pwr_state & REQ_BUS_ON); +-- +2.39.5 + diff --git a/queue-6.6/net-mlx5-use-do_aux_work-for-phc-overflow-checks.patch b/queue-6.6/net-mlx5-use-do_aux_work-for-phc-overflow-checks.patch new file mode 100644 index 0000000000..eb2fb8675d --- /dev/null +++ b/queue-6.6/net-mlx5-use-do_aux_work-for-phc-overflow-checks.patch @@ -0,0 +1,129 @@ +From e7c56ec8ea07312afd4988b34e13624e83ebec22 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 7 Jan 2025 02:48:12 -0800 +Subject: net/mlx5: use do_aux_work for PHC overflow checks + +From: Vadim Fedorenko + +[ Upstream commit e61e6c415ba9ff2b32bb6780ce1b17d1d76238f1 ] + +The overflow_work is using system wq to do overflow checks and updates +for PHC device timecounter, which might be overhelmed by other tasks. +But there is dedicated kthread in PTP subsystem designed for such +things. This patch changes the work queue to proper align with PTP +subsystem and to avoid overloading system work queue. +The adjfine() function acts the same way as overflow check worker, +we can postpone ptp aux worker till the next overflow period after +adjfine() was called. + +Reviewed-by: Dragos Tatulea +Signed-off-by: Vadim Fedorenko +Acked-by: Tariq Toukan +Link: https://patch.msgid.link/20250107104812.380225-1-vadfed@meta.com +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + .../ethernet/mellanox/mlx5/core/lib/clock.c | 24 ++++++++++--------- + include/linux/mlx5/driver.h | 1 - + 2 files changed, 13 insertions(+), 12 deletions(-) + +diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c +index 0c83ef174275a..f00702bf781f1 100644 +--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c ++++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c +@@ -237,17 +237,16 @@ static void mlx5_pps_out(struct work_struct *work) + } + } + +-static void mlx5_timestamp_overflow(struct work_struct *work) ++static long mlx5_timestamp_overflow(struct ptp_clock_info *ptp_info) + { +- struct delayed_work *dwork = to_delayed_work(work); + struct mlx5_core_dev *mdev; + struct mlx5_timer *timer; + struct mlx5_clock *clock; + unsigned long flags; + +- timer = container_of(dwork, struct mlx5_timer, overflow_work); +- clock = container_of(timer, struct mlx5_clock, timer); ++ clock = container_of(ptp_info, struct mlx5_clock, ptp_info); + mdev = container_of(clock, struct mlx5_core_dev, clock); ++ timer = &clock->timer; + + if (mdev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) + goto out; +@@ -258,7 +257,7 @@ static void mlx5_timestamp_overflow(struct work_struct *work) + write_sequnlock_irqrestore(&clock->lock, flags); + + out: +- schedule_delayed_work(&timer->overflow_work, timer->overflow_period); ++ return timer->overflow_period; + } + + static int mlx5_ptp_settime_real_time(struct mlx5_core_dev *mdev, +@@ -435,6 +434,7 @@ static int mlx5_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm) + timer->cycles.mult = mult; + mlx5_update_clock_info_page(mdev); + write_sequnlock_irqrestore(&clock->lock, flags); ++ ptp_schedule_worker(clock->ptp, timer->overflow_period); + + return 0; + } +@@ -770,6 +770,7 @@ static const struct ptp_clock_info mlx5_ptp_clock_info = { + .settime64 = mlx5_ptp_settime, + .enable = NULL, + .verify = NULL, ++ .do_aux_work = mlx5_timestamp_overflow, + }; + + static int mlx5_query_mtpps_pin_mode(struct mlx5_core_dev *mdev, u8 pin, +@@ -970,12 +971,11 @@ static void mlx5_init_overflow_period(struct mlx5_clock *clock) + do_div(ns, NSEC_PER_SEC / HZ); + timer->overflow_period = ns; + +- INIT_DELAYED_WORK(&timer->overflow_work, mlx5_timestamp_overflow); +- if (timer->overflow_period) +- schedule_delayed_work(&timer->overflow_work, 0); +- else ++ if (!timer->overflow_period) { ++ timer->overflow_period = HZ; + mlx5_core_warn(mdev, +- "invalid overflow period, overflow_work is not scheduled\n"); ++ "invalid overflow period, overflow_work is scheduled once per second\n"); ++ } + + if (clock_info) + clock_info->overflow_period = timer->overflow_period; +@@ -1061,6 +1061,9 @@ void mlx5_init_clock(struct mlx5_core_dev *mdev) + + MLX5_NB_INIT(&clock->pps_nb, mlx5_pps_event, PPS_EVENT); + mlx5_eq_notifier_register(mdev, &clock->pps_nb); ++ ++ if (clock->ptp) ++ ptp_schedule_worker(clock->ptp, 0); + } + + void mlx5_cleanup_clock(struct mlx5_core_dev *mdev) +@@ -1077,7 +1080,6 @@ void mlx5_cleanup_clock(struct mlx5_core_dev *mdev) + } + + cancel_work_sync(&clock->pps_info.out_work); +- cancel_delayed_work_sync(&clock->timer.overflow_work); + + if (mdev->clock_info) { + free_page((unsigned long)mdev->clock_info); +diff --git a/include/linux/mlx5/driver.h b/include/linux/mlx5/driver.h +index 38a8ff9c685cb..69d844b34da0d 100644 +--- a/include/linux/mlx5/driver.h ++++ b/include/linux/mlx5/driver.h +@@ -709,7 +709,6 @@ struct mlx5_timer { + struct timecounter tc; + u32 nominal_c_mult; + unsigned long overflow_period; +- struct delayed_work overflow_work; + }; + + struct mlx5_clock { +-- +2.39.5 + diff --git a/queue-6.6/net-ncsi-add-nc-si-1.2-get-mc-mac-address-command.patch b/queue-6.6/net-ncsi-add-nc-si-1.2-get-mc-mac-address-command.patch new file mode 100644 index 0000000000..77ef7b3679 --- /dev/null +++ b/queue-6.6/net-ncsi-add-nc-si-1.2-get-mc-mac-address-command.patch @@ -0,0 +1,173 @@ +From 448064fe6e231117748067aa65d449f9f680d3c3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 14 Nov 2023 10:07:35 -0600 +Subject: net/ncsi: Add NC-SI 1.2 Get MC MAC Address command + +From: Peter Delevoryas + +[ Upstream commit b8291cf3d1180b5b61299922f17c9441616a805a ] + +This change adds support for the NC-SI 1.2 Get MC MAC Address command, +specified here: + +https://www.dmtf.org/sites/default/files/standards/documents/DSP0222_1.2.0.pdf + +It serves the exact same function as the existing OEM Get MAC Address +commands, so if a channel reports that it supports NC-SI 1.2, we prefer +to use the standard command rather than the OEM command. + +Verified with an invalid MAC address and 2 valid ones: + +[ 55.137072] ftgmac100 1e690000.ftgmac eth0: NCSI: Received 3 provisioned MAC addresses +[ 55.137614] ftgmac100 1e690000.ftgmac eth0: NCSI: MAC address 0: 00:00:00:00:00:00 +[ 55.138026] ftgmac100 1e690000.ftgmac eth0: NCSI: MAC address 1: fa:ce:b0:0c:20:22 +[ 55.138528] ftgmac100 1e690000.ftgmac eth0: NCSI: MAC address 2: fa:ce:b0:0c:20:23 +[ 55.139241] ftgmac100 1e690000.ftgmac eth0: NCSI: Unable to assign 00:00:00:00:00:00 to device +[ 55.140098] ftgmac100 1e690000.ftgmac eth0: NCSI: Set MAC address to fa:ce:b0:0c:20:22 + +Signed-off-by: Peter Delevoryas +Signed-off-by: Patrick Williams +Signed-off-by: David S. Miller +Stable-dep-of: 9e2bbab94b88 ("net/ncsi: fix locking in Get MAC Address handling") +Signed-off-by: Sasha Levin +--- + net/ncsi/ncsi-cmd.c | 3 ++- + net/ncsi/ncsi-manage.c | 9 +++++++-- + net/ncsi/ncsi-pkt.h | 10 ++++++++++ + net/ncsi/ncsi-rsp.c | 41 ++++++++++++++++++++++++++++++++++++++++- + 4 files changed, 59 insertions(+), 4 deletions(-) + +diff --git a/net/ncsi/ncsi-cmd.c b/net/ncsi/ncsi-cmd.c +index fd2236ee9a79d..b3ff37a181d73 100644 +--- a/net/ncsi/ncsi-cmd.c ++++ b/net/ncsi/ncsi-cmd.c +@@ -270,7 +270,8 @@ static struct ncsi_cmd_handler { + { NCSI_PKT_CMD_GPS, 0, ncsi_cmd_handler_default }, + { NCSI_PKT_CMD_OEM, -1, ncsi_cmd_handler_oem }, + { NCSI_PKT_CMD_PLDM, 0, NULL }, +- { NCSI_PKT_CMD_GPUUID, 0, ncsi_cmd_handler_default } ++ { NCSI_PKT_CMD_GPUUID, 0, ncsi_cmd_handler_default }, ++ { NCSI_PKT_CMD_GMCMA, 0, ncsi_cmd_handler_default } + }; + + static struct ncsi_request *ncsi_alloc_command(struct ncsi_cmd_arg *nca) +diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c +index 90c6cf676221a..5ecf611c88200 100644 +--- a/net/ncsi/ncsi-manage.c ++++ b/net/ncsi/ncsi-manage.c +@@ -1040,11 +1040,16 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp) + case ncsi_dev_state_config_oem_gma: + nd->state = ncsi_dev_state_config_clear_vids; + +- nca.type = NCSI_PKT_CMD_OEM; + nca.package = np->id; + nca.channel = nc->id; + ndp->pending_req_num = 1; +- ret = ncsi_gma_handler(&nca, nc->version.mf_id); ++ if (nc->version.major >= 1 && nc->version.minor >= 2) { ++ nca.type = NCSI_PKT_CMD_GMCMA; ++ ret = ncsi_xmit_cmd(&nca); ++ } else { ++ nca.type = NCSI_PKT_CMD_OEM; ++ ret = ncsi_gma_handler(&nca, nc->version.mf_id); ++ } + if (ret < 0) + schedule_work(&ndp->work); + +diff --git a/net/ncsi/ncsi-pkt.h b/net/ncsi/ncsi-pkt.h +index c9d1da34dc4dc..f2f3b5c1b9412 100644 +--- a/net/ncsi/ncsi-pkt.h ++++ b/net/ncsi/ncsi-pkt.h +@@ -338,6 +338,14 @@ struct ncsi_rsp_gpuuid_pkt { + __be32 checksum; + }; + ++/* Get MC MAC Address */ ++struct ncsi_rsp_gmcma_pkt { ++ struct ncsi_rsp_pkt_hdr rsp; ++ unsigned char address_count; ++ unsigned char reserved[3]; ++ unsigned char addresses[][ETH_ALEN]; ++}; ++ + /* AEN: Link State Change */ + struct ncsi_aen_lsc_pkt { + struct ncsi_aen_pkt_hdr aen; /* AEN header */ +@@ -398,6 +406,7 @@ struct ncsi_aen_hncdsc_pkt { + #define NCSI_PKT_CMD_GPUUID 0x52 /* Get package UUID */ + #define NCSI_PKT_CMD_QPNPR 0x56 /* Query Pending NC PLDM request */ + #define NCSI_PKT_CMD_SNPR 0x57 /* Send NC PLDM Reply */ ++#define NCSI_PKT_CMD_GMCMA 0x58 /* Get MC MAC Address */ + + + /* NCSI packet responses */ +@@ -433,6 +442,7 @@ struct ncsi_aen_hncdsc_pkt { + #define NCSI_PKT_RSP_GPUUID (NCSI_PKT_CMD_GPUUID + 0x80) + #define NCSI_PKT_RSP_QPNPR (NCSI_PKT_CMD_QPNPR + 0x80) + #define NCSI_PKT_RSP_SNPR (NCSI_PKT_CMD_SNPR + 0x80) ++#define NCSI_PKT_RSP_GMCMA (NCSI_PKT_CMD_GMCMA + 0x80) + + /* NCSI response code/reason */ + #define NCSI_PKT_RSP_C_COMPLETED 0x0000 /* Command Completed */ +diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c +index f22d67cb04d37..e28be33bdf2c4 100644 +--- a/net/ncsi/ncsi-rsp.c ++++ b/net/ncsi/ncsi-rsp.c +@@ -1093,6 +1093,44 @@ static int ncsi_rsp_handler_netlink(struct ncsi_request *nr) + return ret; + } + ++static int ncsi_rsp_handler_gmcma(struct ncsi_request *nr) ++{ ++ struct ncsi_dev_priv *ndp = nr->ndp; ++ struct net_device *ndev = ndp->ndev.dev; ++ struct ncsi_rsp_gmcma_pkt *rsp; ++ struct sockaddr saddr; ++ int ret = -1; ++ int i; ++ ++ rsp = (struct ncsi_rsp_gmcma_pkt *)skb_network_header(nr->rsp); ++ saddr.sa_family = ndev->type; ++ ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE; ++ ++ netdev_info(ndev, "NCSI: Received %d provisioned MAC addresses\n", ++ rsp->address_count); ++ for (i = 0; i < rsp->address_count; i++) { ++ netdev_info(ndev, "NCSI: MAC address %d: %02x:%02x:%02x:%02x:%02x:%02x\n", ++ i, rsp->addresses[i][0], rsp->addresses[i][1], ++ rsp->addresses[i][2], rsp->addresses[i][3], ++ rsp->addresses[i][4], rsp->addresses[i][5]); ++ } ++ ++ for (i = 0; i < rsp->address_count; i++) { ++ memcpy(saddr.sa_data, &rsp->addresses[i], ETH_ALEN); ++ ret = ndev->netdev_ops->ndo_set_mac_address(ndev, &saddr); ++ if (ret < 0) { ++ netdev_warn(ndev, "NCSI: Unable to assign %pM to device\n", ++ saddr.sa_data); ++ continue; ++ } ++ netdev_warn(ndev, "NCSI: Set MAC address to %pM\n", saddr.sa_data); ++ break; ++ } ++ ++ ndp->gma_flag = ret == 0; ++ return ret; ++} ++ + static struct ncsi_rsp_handler { + unsigned char type; + int payload; +@@ -1129,7 +1167,8 @@ static struct ncsi_rsp_handler { + { NCSI_PKT_RSP_PLDM, -1, ncsi_rsp_handler_pldm }, + { NCSI_PKT_RSP_GPUUID, 20, ncsi_rsp_handler_gpuuid }, + { NCSI_PKT_RSP_QPNPR, -1, ncsi_rsp_handler_pldm }, +- { NCSI_PKT_RSP_SNPR, -1, ncsi_rsp_handler_pldm } ++ { NCSI_PKT_RSP_SNPR, -1, ncsi_rsp_handler_pldm }, ++ { NCSI_PKT_RSP_GMCMA, -1, ncsi_rsp_handler_gmcma }, + }; + + int ncsi_rcv_rsp(struct sk_buff *skb, struct net_device *dev, +-- +2.39.5 + diff --git a/queue-6.6/net-ncsi-fix-locking-in-get-mac-address-handling.patch b/queue-6.6/net-ncsi-fix-locking-in-get-mac-address-handling.patch new file mode 100644 index 0000000000..a54f024323 --- /dev/null +++ b/queue-6.6/net-ncsi-fix-locking-in-get-mac-address-handling.patch @@ -0,0 +1,137 @@ +From 30cda048122dafacbb797ed8dcabb760e6c800a6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 9 Jan 2025 17:50:54 +0300 +Subject: net/ncsi: fix locking in Get MAC Address handling + +From: Paul Fertser + +[ Upstream commit 9e2bbab94b88295dcc57c7580393c9ee08d7314d ] + +Obtaining RTNL lock in a response handler is not allowed since it runs +in an atomic softirq context. Postpone setting the MAC address by adding +a dedicated step to the configuration FSM. + +Fixes: 790071347a0a ("net/ncsi: change from ndo_set_mac_address to dev_set_mac_address") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/20241129-potin-revert-ncsi-set-mac-addr-v1-1-94ea2cb596af@gmail.com +Signed-off-by: Paul Fertser +Tested-by: Potin Lai +Link: https://patch.msgid.link/20250109145054.30925-1-fercerpav@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/ncsi/internal.h | 2 ++ + net/ncsi/ncsi-manage.c | 16 ++++++++++++++-- + net/ncsi/ncsi-rsp.c | 19 ++++++------------- + 3 files changed, 22 insertions(+), 15 deletions(-) + +diff --git a/net/ncsi/internal.h b/net/ncsi/internal.h +index ef0f8f73826f5..4e0842df5234e 100644 +--- a/net/ncsi/internal.h ++++ b/net/ncsi/internal.h +@@ -289,6 +289,7 @@ enum { + ncsi_dev_state_config_sp = 0x0301, + ncsi_dev_state_config_cis, + ncsi_dev_state_config_oem_gma, ++ ncsi_dev_state_config_apply_mac, + ncsi_dev_state_config_clear_vids, + ncsi_dev_state_config_svf, + ncsi_dev_state_config_ev, +@@ -322,6 +323,7 @@ struct ncsi_dev_priv { + #define NCSI_DEV_RESHUFFLE 4 + #define NCSI_DEV_RESET 8 /* Reset state of NC */ + unsigned int gma_flag; /* OEM GMA flag */ ++ struct sockaddr pending_mac; /* MAC address received from GMA */ + spinlock_t lock; /* Protect the NCSI device */ + unsigned int package_probe_id;/* Current ID during probe */ + unsigned int package_num; /* Number of packages */ +diff --git a/net/ncsi/ncsi-manage.c b/net/ncsi/ncsi-manage.c +index 5ecf611c88200..e46b930357803 100644 +--- a/net/ncsi/ncsi-manage.c ++++ b/net/ncsi/ncsi-manage.c +@@ -1038,7 +1038,7 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp) + : ncsi_dev_state_config_clear_vids; + break; + case ncsi_dev_state_config_oem_gma: +- nd->state = ncsi_dev_state_config_clear_vids; ++ nd->state = ncsi_dev_state_config_apply_mac; + + nca.package = np->id; + nca.channel = nc->id; +@@ -1050,10 +1050,22 @@ static void ncsi_configure_channel(struct ncsi_dev_priv *ndp) + nca.type = NCSI_PKT_CMD_OEM; + ret = ncsi_gma_handler(&nca, nc->version.mf_id); + } +- if (ret < 0) ++ if (ret < 0) { ++ nd->state = ncsi_dev_state_config_clear_vids; + schedule_work(&ndp->work); ++ } + + break; ++ case ncsi_dev_state_config_apply_mac: ++ rtnl_lock(); ++ ret = dev_set_mac_address(dev, &ndp->pending_mac, NULL); ++ rtnl_unlock(); ++ if (ret < 0) ++ netdev_warn(dev, "NCSI: 'Writing MAC address to device failed\n"); ++ ++ nd->state = ncsi_dev_state_config_clear_vids; ++ ++ fallthrough; + case ncsi_dev_state_config_clear_vids: + case ncsi_dev_state_config_svf: + case ncsi_dev_state_config_ev: +diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c +index e28be33bdf2c4..14bd66909ca45 100644 +--- a/net/ncsi/ncsi-rsp.c ++++ b/net/ncsi/ncsi-rsp.c +@@ -628,16 +628,14 @@ static int ncsi_rsp_handler_snfc(struct ncsi_request *nr) + static int ncsi_rsp_handler_oem_gma(struct ncsi_request *nr, int mfr_id) + { + struct ncsi_dev_priv *ndp = nr->ndp; ++ struct sockaddr *saddr = &ndp->pending_mac; + struct net_device *ndev = ndp->ndev.dev; + struct ncsi_rsp_oem_pkt *rsp; +- struct sockaddr saddr; + u32 mac_addr_off = 0; +- int ret = 0; + + /* Get the response header */ + rsp = (struct ncsi_rsp_oem_pkt *)skb_network_header(nr->rsp); + +- saddr.sa_family = ndev->type; + ndev->priv_flags |= IFF_LIVE_ADDR_CHANGE; + if (mfr_id == NCSI_OEM_MFR_BCM_ID) + mac_addr_off = BCM_MAC_ADDR_OFFSET; +@@ -646,22 +644,17 @@ static int ncsi_rsp_handler_oem_gma(struct ncsi_request *nr, int mfr_id) + else if (mfr_id == NCSI_OEM_MFR_INTEL_ID) + mac_addr_off = INTEL_MAC_ADDR_OFFSET; + +- memcpy(saddr.sa_data, &rsp->data[mac_addr_off], ETH_ALEN); ++ saddr->sa_family = ndev->type; ++ memcpy(saddr->sa_data, &rsp->data[mac_addr_off], ETH_ALEN); + if (mfr_id == NCSI_OEM_MFR_BCM_ID || mfr_id == NCSI_OEM_MFR_INTEL_ID) +- eth_addr_inc((u8 *)saddr.sa_data); +- if (!is_valid_ether_addr((const u8 *)saddr.sa_data)) ++ eth_addr_inc((u8 *)saddr->sa_data); ++ if (!is_valid_ether_addr((const u8 *)saddr->sa_data)) + return -ENXIO; + + /* Set the flag for GMA command which should only be called once */ + ndp->gma_flag = 1; + +- rtnl_lock(); +- ret = dev_set_mac_address(ndev, &saddr, NULL); +- rtnl_unlock(); +- if (ret < 0) +- netdev_warn(ndev, "NCSI: 'Writing mac address to device failed\n"); +- +- return ret; ++ return 0; + } + + /* Response handler for Mellanox card */ +-- +2.39.5 + diff --git a/queue-6.6/net-wwan-iosm-fix-hibernation-by-re-binding-the-driv.patch b/queue-6.6/net-wwan-iosm-fix-hibernation-by-re-binding-the-driv.patch new file mode 100644 index 0000000000..20608f6823 --- /dev/null +++ b/queue-6.6/net-wwan-iosm-fix-hibernation-by-re-binding-the-driv.patch @@ -0,0 +1,146 @@ +From 838571e7ee71db6b3be9e77ff32adc8a61ef0c8c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 9 Jan 2025 00:33:50 +0100 +Subject: net: wwan: iosm: Fix hibernation by re-binding the driver around it + +From: Maciej S. Szmigiero + +[ Upstream commit 0b6f6593aa8c3a05f155c12fd0e7ad33a5149c31 ] + +Currently, the driver is seriously broken with respect to the +hibernation (S4): after image restore the device is back into +IPC_MEM_EXEC_STAGE_BOOT (which AFAIK means bootloader stage) and needs +full re-launch of the rest of its firmware, but the driver restore +handler treats the device as merely sleeping and just sends it a +wake-up command. + +This wake-up command times out but device nodes (/dev/wwan*) remain +accessible. +However attempting to use them causes the bootloader to crash and +enter IPC_MEM_EXEC_STAGE_CD_READY stage (which apparently means "a crash +dump is ready"). + +It seems that the device cannot be re-initialized from this crashed +stage without toggling some reset pin (on my test platform that's +apparently what the device _RST ACPI method does). + +While it would theoretically be possible to rewrite the driver to tear +down the whole MUX / IPC layers on hibernation (so the bootloader does +not crash from improper access) and then re-launch the device on +restore this would require significant refactoring of the driver +(believe me, I've tried), since there are quite a few assumptions +hard-coded in the driver about the device never being partially +de-initialized (like channels other than devlink cannot be closed, +for example). +Probably this would also need some programming guide for this hardware. + +Considering that the driver seems orphaned [1] and other people are +hitting this issue too [2] fix it by simply unbinding the PCI driver +before hibernation and re-binding it after restore, much like +USB_QUIRK_RESET_RESUME does for USB devices that exhibit a similar +problem. + +Tested on XMM7360 in HP EliteBook 855 G7 both with s2idle (which uses +the existing suspend / resume handlers) and S4 (which uses the new code). + +[1]: https://lore.kernel.org/all/c248f0b4-2114-4c61-905f-466a786bdebb@leemhuis.info/ +[2]: +https://github.com/xmm7360/xmm7360-pci/issues/211#issuecomment-1804139413 + +Reviewed-by: Sergey Ryazanov +Signed-off-by: Maciej S. Szmigiero +Link: https://patch.msgid.link/e60287ebdb0ab54c4075071b72568a40a75d0205.1736372610.git.mail@maciej.szmigiero.name +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/wwan/iosm/iosm_ipc_pcie.c | 56 ++++++++++++++++++++++++++- + 1 file changed, 55 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/wwan/iosm/iosm_ipc_pcie.c b/drivers/net/wwan/iosm/iosm_ipc_pcie.c +index 04517bd3325a2..a066977af0be5 100644 +--- a/drivers/net/wwan/iosm/iosm_ipc_pcie.c ++++ b/drivers/net/wwan/iosm/iosm_ipc_pcie.c +@@ -6,6 +6,7 @@ + #include + #include + #include ++#include + #include + + #include "iosm_ipc_imem.h" +@@ -18,6 +19,7 @@ MODULE_LICENSE("GPL v2"); + /* WWAN GUID */ + static guid_t wwan_acpi_guid = GUID_INIT(0xbad01b75, 0x22a8, 0x4f48, 0x87, 0x92, + 0xbd, 0xde, 0x94, 0x67, 0x74, 0x7d); ++static bool pci_registered; + + static void ipc_pcie_resources_release(struct iosm_pcie *ipc_pcie) + { +@@ -448,7 +450,6 @@ static struct pci_driver iosm_ipc_driver = { + }, + .id_table = iosm_ipc_ids, + }; +-module_pci_driver(iosm_ipc_driver); + + int ipc_pcie_addr_map(struct iosm_pcie *ipc_pcie, unsigned char *data, + size_t size, dma_addr_t *mapping, int direction) +@@ -530,3 +531,56 @@ void ipc_pcie_kfree_skb(struct iosm_pcie *ipc_pcie, struct sk_buff *skb) + IPC_CB(skb)->mapping = 0; + dev_kfree_skb(skb); + } ++ ++static int pm_notify(struct notifier_block *nb, unsigned long mode, void *_unused) ++{ ++ if (mode == PM_HIBERNATION_PREPARE || mode == PM_RESTORE_PREPARE) { ++ if (pci_registered) { ++ pci_unregister_driver(&iosm_ipc_driver); ++ pci_registered = false; ++ } ++ } else if (mode == PM_POST_HIBERNATION || mode == PM_POST_RESTORE) { ++ if (!pci_registered) { ++ int ret; ++ ++ ret = pci_register_driver(&iosm_ipc_driver); ++ if (ret) { ++ pr_err(KBUILD_MODNAME ": unable to re-register PCI driver: %d\n", ++ ret); ++ } else { ++ pci_registered = true; ++ } ++ } ++ } ++ ++ return 0; ++} ++ ++static struct notifier_block pm_notifier = { ++ .notifier_call = pm_notify, ++}; ++ ++static int __init iosm_ipc_driver_init(void) ++{ ++ int ret; ++ ++ ret = pci_register_driver(&iosm_ipc_driver); ++ if (ret) ++ return ret; ++ ++ pci_registered = true; ++ ++ register_pm_notifier(&pm_notifier); ++ ++ return 0; ++} ++module_init(iosm_ipc_driver_init); ++ ++static void __exit iosm_ipc_driver_exit(void) ++{ ++ unregister_pm_notifier(&pm_notifier); ++ ++ if (pci_registered) ++ pci_unregister_driver(&iosm_ipc_driver); ++} ++module_exit(iosm_ipc_driver_exit); +-- +2.39.5 + diff --git a/queue-6.6/platform-x86-acer-wmi-ignore-ac-events.patch b/queue-6.6/platform-x86-acer-wmi-ignore-ac-events.patch new file mode 100644 index 0000000000..8d2c285ee9 --- /dev/null +++ b/queue-6.6/platform-x86-acer-wmi-ignore-ac-events.patch @@ -0,0 +1,53 @@ +From 5ededee8540534a724ecc1e7aa078807d62c0311 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 19 Jan 2025 21:17:22 +0100 +Subject: platform/x86: acer-wmi: Ignore AC events +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Armin Wolf + +[ Upstream commit f6bfa25c6665f8721421ea94fe506cc22f1d4b43 ] + +On the Acer Swift SFG14-41, the events 8 - 1 and 8 - 0 are printed on +AC connect/disconnect. Ignore those events to avoid spamming the +kernel log with error messages. + +Reported-by: Farhan Anwar +Closes: https://lore.kernel.org/platform-driver-x86/2ffb529d-e7c8-4026-a3b8-120c8e7afec8@gmail.com +Tested-by: Rayan Margham +Reviewed-by: Ilpo Järvinen +Signed-off-by: Armin Wolf +Link: https://lore.kernel.org/r/20250119201723.11102-2-W_Armin@gmx.de +Signed-off-by: Ilpo Järvinen +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/acer-wmi.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c +index 377a0becd1a18..868faccfb8628 100644 +--- a/drivers/platform/x86/acer-wmi.c ++++ b/drivers/platform/x86/acer-wmi.c +@@ -88,6 +88,7 @@ enum acer_wmi_event_ids { + WMID_HOTKEY_EVENT = 0x1, + WMID_ACCEL_OR_KBD_DOCK_EVENT = 0x5, + WMID_GAMING_TURBO_KEY_EVENT = 0x7, ++ WMID_AC_EVENT = 0x8, + }; + + static const struct key_entry acer_wmi_keymap[] __initconst = { +@@ -1999,6 +2000,9 @@ static void acer_wmi_notify(u32 value, void *context) + if (return_value.key_num == 0x4) + acer_toggle_turbo(); + break; ++ case WMID_AC_EVENT: ++ /* We ignore AC events here */ ++ break; + default: + pr_warn("Unknown function number - %d - %d\n", + return_value.function, return_value.key_num); +-- +2.39.5 + diff --git a/queue-6.6/platform-x86-int3472-check-for-adev-null.patch b/queue-6.6/platform-x86-int3472-check-for-adev-null.patch new file mode 100644 index 0000000000..65bdf8d569 --- /dev/null +++ b/queue-6.6/platform-x86-int3472-check-for-adev-null.patch @@ -0,0 +1,60 @@ +From e3ccbc7ec6d7dfcfbad731483d58d9bd0a946f20 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 9 Dec 2024 23:05:19 +0100 +Subject: platform/x86: int3472: Check for adev == NULL +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Hans de Goede + +[ Upstream commit cd2fd6eab480dfc247b737cf7a3d6b009c4d0f1c ] + +Not all devices have an ACPI companion fwnode, so adev might be NULL. This +can e.g. (theoretically) happen when a user manually binds one of +the int3472 drivers to another i2c/platform device through sysfs. + +Add a check for adev not being set and return -ENODEV in that case to +avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer(). + +Signed-off-by: Hans de Goede +Link: https://lore.kernel.org/r/20241209220522.25288-1-hdegoede@redhat.com +Reviewed-by: Ilpo Järvinen +Signed-off-by: Ilpo Järvinen +Signed-off-by: Sasha Levin +--- + drivers/platform/x86/intel/int3472/discrete.c | 3 +++ + drivers/platform/x86/intel/int3472/tps68470.c | 3 +++ + 2 files changed, 6 insertions(+) + +diff --git a/drivers/platform/x86/intel/int3472/discrete.c b/drivers/platform/x86/intel/int3472/discrete.c +index e33c2d75975cf..d56f79043f5e2 100644 +--- a/drivers/platform/x86/intel/int3472/discrete.c ++++ b/drivers/platform/x86/intel/int3472/discrete.c +@@ -284,6 +284,9 @@ static int skl_int3472_discrete_probe(struct platform_device *pdev) + struct int3472_cldb cldb; + int ret; + ++ if (!adev) ++ return -ENODEV; ++ + ret = skl_int3472_fill_cldb(adev, &cldb); + if (ret) { + dev_err(&pdev->dev, "Couldn't fill CLDB structure\n"); +diff --git a/drivers/platform/x86/intel/int3472/tps68470.c b/drivers/platform/x86/intel/int3472/tps68470.c +index 1e107fd49f828..81ac4c6919630 100644 +--- a/drivers/platform/x86/intel/int3472/tps68470.c ++++ b/drivers/platform/x86/intel/int3472/tps68470.c +@@ -152,6 +152,9 @@ static int skl_int3472_tps68470_probe(struct i2c_client *client) + int ret; + int i; + ++ if (!adev) ++ return -ENODEV; ++ + n_consumers = skl_int3472_fill_clk_pdata(&client->dev, &clk_pdata); + if (n_consumers < 0) + return n_consumers; +-- +2.39.5 + diff --git a/queue-6.6/printk-fix-signed-integer-overflow-when-defining-log.patch b/queue-6.6/printk-fix-signed-integer-overflow-when-defining-log.patch new file mode 100644 index 0000000000..a153f4f9e7 --- /dev/null +++ b/queue-6.6/printk-fix-signed-integer-overflow-when-defining-log.patch @@ -0,0 +1,41 @@ +From 12927b8bdd4da6572059f42fcb970132f7ba004c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 28 Sep 2024 19:36:08 +0800 +Subject: printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAX + +From: Kuan-Wei Chiu + +[ Upstream commit 3d6f83df8ff2d5de84b50377e4f0d45e25311c7a ] + +Shifting 1 << 31 on a 32-bit int causes signed integer overflow, which +leads to undefined behavior. To prevent this, cast 1 to u32 before +performing the shift, ensuring well-defined behavior. + +This change explicitly avoids any potential overflow by ensuring that +the shift occurs on an unsigned 32-bit integer. + +Signed-off-by: Kuan-Wei Chiu +Acked-by: Petr Mladek +Link: https://lore.kernel.org/r/20240928113608.1438087-1-visitorckw@gmail.com +Signed-off-by: Petr Mladek +Signed-off-by: Sasha Levin +--- + kernel/printk/printk.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c +index 0fca282c0a254..dcdf449615bda 100644 +--- a/kernel/printk/printk.c ++++ b/kernel/printk/printk.c +@@ -474,7 +474,7 @@ static struct latched_seq clear_seq = { + /* record buffer */ + #define LOG_ALIGN __alignof__(unsigned long) + #define __LOG_BUF_LEN (1 << CONFIG_LOG_BUF_SHIFT) +-#define LOG_BUF_LEN_MAX (u32)(1 << 31) ++#define LOG_BUF_LEN_MAX ((u32)1 << 31) + static char __log_buf[__LOG_BUF_LEN] __aligned(LOG_ALIGN); + static char *log_buf = __log_buf; + static u32 log_buf_len = __LOG_BUF_LEN; +-- +2.39.5 + diff --git a/queue-6.6/s390-stackleak-use-exrl-instead-of-ex-in-__stackleak.patch b/queue-6.6/s390-stackleak-use-exrl-instead-of-ex-in-__stackleak.patch new file mode 100644 index 0000000000..8cfc4e3f99 --- /dev/null +++ b/queue-6.6/s390-stackleak-use-exrl-instead-of-ex-in-__stackleak.patch @@ -0,0 +1,38 @@ +From eb4d484cccfe4da0c55d35620f2d37e4a61153a0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 8 Jan 2025 15:27:02 +0100 +Subject: s390/stackleak: Use exrl instead of ex in __stackleak_poison() + +From: Sven Schnelle + +[ Upstream commit a88c26bb8e04ee5f2678225c0130a5fbc08eef85 ] + +exrl is present in all machines currently supported, therefore prefer +it over ex. This saves one instruction and doesn't need an additional +register to hold the address of the target instruction. + +Signed-off-by: Sven Schnelle +Reviewed-by: Heiko Carstens +Signed-off-by: Alexander Gordeev +Signed-off-by: Sasha Levin +--- + arch/s390/include/asm/processor.h | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h +index e7338ed540d8f..2f373e8cfed33 100644 +--- a/arch/s390/include/asm/processor.h ++++ b/arch/s390/include/asm/processor.h +@@ -140,8 +140,7 @@ static __always_inline void __stackleak_poison(unsigned long erase_low, + " la %[addr],256(%[addr])\n" + " brctg %[tmp],0b\n" + "1: stg %[poison],0(%[addr])\n" +- " larl %[tmp],3f\n" +- " ex %[count],0(%[tmp])\n" ++ " exrl %[count],3f\n" + " j 4f\n" + "2: stg %[poison],0(%[addr])\n" + " j 4f\n" +-- +2.39.5 + diff --git a/queue-6.6/safesetid-check-size-of-policy-writes.patch b/queue-6.6/safesetid-check-size-of-policy-writes.patch new file mode 100644 index 0000000000..3ae88f807f --- /dev/null +++ b/queue-6.6/safesetid-check-size-of-policy-writes.patch @@ -0,0 +1,42 @@ +From 3dbae63588267889710a0cd64eb78aff3be3a39d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 17 Dec 2024 10:26:57 -0800 +Subject: safesetid: check size of policy writes + +From: Leo Stone + +[ Upstream commit f09ff307c7299392f1c88f763299e24bc99811c7 ] + +syzbot attempts to write a buffer with a large size to a sysfs entry +with writes handled by handle_policy_update(), triggering a warning +in kmalloc. + +Check the size specified for write buffers before allocating. + +Reported-by: syzbot+4eb7a741b3216020043a@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=4eb7a741b3216020043a +Signed-off-by: Leo Stone +[PM: subject tweak] +Signed-off-by: Paul Moore +Signed-off-by: Sasha Levin +--- + security/safesetid/securityfs.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/security/safesetid/securityfs.c b/security/safesetid/securityfs.c +index 25310468bcddf..8e1ffd70b18ab 100644 +--- a/security/safesetid/securityfs.c ++++ b/security/safesetid/securityfs.c +@@ -143,6 +143,9 @@ static ssize_t handle_policy_update(struct file *file, + char *buf, *p, *end; + int err; + ++ if (len >= KMALLOC_MAX_SIZE) ++ return -EINVAL; ++ + pol = kmalloc(sizeof(struct setid_ruleset), GFP_KERNEL); + if (!pol) + return -ENOMEM; +-- +2.39.5 + diff --git a/queue-6.6/sched-don-t-try-to-catch-up-excess-steal-time.patch b/queue-6.6/sched-don-t-try-to-catch-up-excess-steal-time.patch new file mode 100644 index 0000000000..1bd4f1ad65 --- /dev/null +++ b/queue-6.6/sched-don-t-try-to-catch-up-excess-steal-time.patch @@ -0,0 +1,76 @@ +From 4ce87a40b6f1a2938b555ea33725dcafde3e34ab Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 18 Nov 2024 13:37:45 +0900 +Subject: sched: Don't try to catch up excess steal time. + +From: Suleiman Souhlal + +[ Upstream commit 108ad0999085df2366dd9ef437573955cb3f5586 ] + +When steal time exceeds the measured delta when updating clock_task, we +currently try to catch up the excess in future updates. +However, this results in inaccurate run times for the future things using +clock_task, in some situations, as they end up getting additional steal +time that did not actually happen. +This is because there is a window between reading the elapsed time in +update_rq_clock() and sampling the steal time in update_rq_clock_task(). +If the VCPU gets preempted between those two points, any additional +steal time is accounted to the outgoing task even though the calculated +delta did not actually contain any of that "stolen" time. +When this race happens, we can end up with steal time that exceeds the +calculated delta, and the previous code would try to catch up that excess +steal time in future clock updates, which is given to the next, +incoming task, even though it did not actually have any time stolen. + +This behavior is particularly bad when steal time can be very long, +which we've seen when trying to extend steal time to contain the duration +that the host was suspended [0]. When this happens, clock_task stays +frozen, during which the running task stays running for the whole +duration, since its run time doesn't increase. +However the race can happen even under normal operation. + +Ideally we would read the elapsed cpu time and the steal time atomically, +to prevent this race from happening in the first place, but doing so +is non-trivial. + +Since the time between those two points isn't otherwise accounted anywhere, +neither to the outgoing task nor the incoming task (because the "end of +outgoing task" and "start of incoming task" timestamps are the same), +I would argue that the right thing to do is to simply drop any excess steal +time, in order to prevent these issues. + +[0] https://lore.kernel.org/kvm/20240820043543.837914-1-suleiman@google.com/ + +Signed-off-by: Suleiman Souhlal +Signed-off-by: Peter Zijlstra (Intel) +Link: https://lore.kernel.org/r/20241118043745.1857272-1-suleiman@google.com +Signed-off-by: Sasha Levin +--- + kernel/sched/core.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/kernel/sched/core.c b/kernel/sched/core.c +index 86606fb9e6bc6..c686d826a91cf 100644 +--- a/kernel/sched/core.c ++++ b/kernel/sched/core.c +@@ -726,13 +726,15 @@ static void update_rq_clock_task(struct rq *rq, s64 delta) + #endif + #ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING + if (static_key_false((¶virt_steal_rq_enabled))) { +- steal = paravirt_steal_clock(cpu_of(rq)); ++ u64 prev_steal; ++ ++ steal = prev_steal = paravirt_steal_clock(cpu_of(rq)); + steal -= rq->prev_steal_time_rq; + + if (unlikely(steal > delta)) + steal = delta; + +- rq->prev_steal_time_rq += steal; ++ rq->prev_steal_time_rq = prev_steal; + delta -= steal; + } + #endif +-- +2.39.5 + diff --git a/queue-6.6/selftests-net-ipsec-fix-null-pointer-dereference-in-.patch b/queue-6.6/selftests-net-ipsec-fix-null-pointer-dereference-in-.patch new file mode 100644 index 0000000000..ead5af3052 --- /dev/null +++ b/queue-6.6/selftests-net-ipsec-fix-null-pointer-dereference-in-.patch @@ -0,0 +1,50 @@ +From 611a3a19ca8ff99f184b66857f9ea68a8ae4a103 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 16 Jan 2025 09:30:37 +0800 +Subject: selftests/net/ipsec: Fix Null pointer dereference in rtattr_pack() + +From: Liu Ye + +[ Upstream commit 3a0b7fa095212b51ed63892540c4f249991a2d74 ] + +Address Null pointer dereference / undefined behavior in rtattr_pack +(note that size is 0 in the bad case). + +Flagged by cppcheck as: + tools/testing/selftests/net/ipsec.c:230:25: warning: Possible null pointer + dereference: payload [nullPointer] + memcpy(RTA_DATA(attr), payload, size); + ^ + tools/testing/selftests/net/ipsec.c:1618:54: note: Calling function 'rtattr_pack', + 4th argument 'NULL' value is 0 + if (rtattr_pack(&req.nh, sizeof(req), XFRMA_IF_ID, NULL, 0)) { + ^ + tools/testing/selftests/net/ipsec.c:230:25: note: Null pointer dereference + memcpy(RTA_DATA(attr), payload, size); + ^ +Signed-off-by: Liu Ye + +Link: https://patch.msgid.link/20250116013037.29470-1-liuye@kylinos.cn +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + tools/testing/selftests/net/ipsec.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/tools/testing/selftests/net/ipsec.c b/tools/testing/selftests/net/ipsec.c +index be4a30a0d02ae..9b44a091802cb 100644 +--- a/tools/testing/selftests/net/ipsec.c ++++ b/tools/testing/selftests/net/ipsec.c +@@ -227,7 +227,8 @@ static int rtattr_pack(struct nlmsghdr *nh, size_t req_sz, + + attr->rta_len = RTA_LENGTH(size); + attr->rta_type = rta_type; +- memcpy(RTA_DATA(attr), payload, size); ++ if (payload) ++ memcpy(RTA_DATA(attr), payload, size); + + return 0; + } +-- +2.39.5 + diff --git a/queue-6.6/series b/queue-6.6/series new file mode 100644 index 0000000000..a727a0e29d --- /dev/null +++ b/queue-6.6/series @@ -0,0 +1,59 @@ +btrfs-fix-assertion-failure-when-splitting-ordered-e.patch +btrfs-fix-use-after-free-when-attempting-to-join-an-.patch +arm64-mm-ensure-adequate-huge_max_hstate.patch +exec-fix-up-proc-pid-comm-in-the-execveat-at_empty_p.patch +s390-stackleak-use-exrl-instead-of-ex-in-__stackleak.patch +btrfs-fix-data-race-when-accessing-the-inode-s-disk_.patch +btrfs-convert-bug_on-in-btrfs_reloc_cow_block-to-pro.patch +sched-don-t-try-to-catch-up-excess-steal-time.patch +lockdep-fix-upper-limit-for-lockdep_-_bits-configs.patch +x86-amd_nb-restrict-init-function-to-amd-based-syste.patch +drm-virtio-new-fence-for-every-plane-update.patch +printk-fix-signed-integer-overflow-when-defining-log.patch +drm-connector-add-mutex-to-protect-eld-from-concurre.patch +drm-bridge-anx7625-use-eld_mutex-to-protect-access-t.patch +drm-bridge-ite-it66121-use-eld_mutex-to-protect-acce.patch +drm-amd-display-use-eld_mutex-to-protect-access-to-c.patch +drm-exynos-hdmi-use-eld_mutex-to-protect-access-to-c.patch +drm-radeon-use-eld_mutex-to-protect-access-to-connec.patch +drm-sti-hdmi-use-eld_mutex-to-protect-access-to-conn.patch +drm-vc4-hdmi-use-eld_mutex-to-protect-access-to-conn.patch +drm-amd-display-fix-mode-cutoff-in-dsc-passthrough-t.patch +drm-bridge-it6505-change-definition-max_hdcp_down_st.patch +drm-bridge-it6505-fix-hdcp-bstatus-check.patch +drm-bridge-it6505-fix-hdcp-encryption-when-r0-ready.patch +drm-bridge-it6505-fix-hdcp-cts-compare-v-matching.patch +drm-bridge-it6505-fix-hdcp-cts-ksv-list-wait-timer.patch +safesetid-check-size-of-policy-writes.patch +wifi-rtw89-add-crystal_cap-check-to-avoid-setting-as.patch +tun-fix-group-permission-check.patch +mmc-core-respect-quirk_max_rate-for-non-uhs-sdio-car.patch +wifi-brcmsmac-add-gain-range-check-to-wlc_phy_iqcal_.patch +tomoyo-don-t-emit-warning-in-tomoyo_write_control.patch +mfd-lpc_ich-add-another-gemini-lake-isa-bridge-pci-d.patch +clk-qcom-make-gcc_8150-depend-on-qcom_gdsc.patch +hid-wacom-add-pci-wacom-device-support.patch +net-mlx5-use-do_aux_work-for-phc-overflow-checks.patch +wifi-brcmfmac-check-the-return-value-of-of_property_.patch +wifi-iwlwifi-avoid-memory-leak.patch +i2c-force-elan06fa-touchpad-i2c-bus-freq-to-100khz.patch +apei-ghes-have-ghes-honor-the-panic-setting.patch +bluetooth-mgmt-fix-slab-use-after-free-read-in-mgmt_.patch +net-wwan-iosm-fix-hibernation-by-re-binding-the-driv.patch +mmc-sdhci-msm-correctly-set-the-load-for-the-regulat.patch +tipc-re-order-conditions-in-tipc_crypto_key_rcv.patch +selftests-net-ipsec-fix-null-pointer-dereference-in-.patch +x86-kexec-allocate-pgd-for-x86_64-transition-page-ta.patch +iommu-arm-smmu-qcom-add-sdm670-adreno-iommu-compatib.patch +iommu-arm-smmu-v3-clean-up-more-on-probe-failure.patch +platform-x86-int3472-check-for-adev-null.patch +asoc-soc-pcm-don-t-use-soc_pcm_ret-on-.prepare-callb.patch +asoc-amd-add-acpi-dependency-to-fix-build-error.patch +input-allocate-keycode-for-phone-linking.patch +platform-x86-acer-wmi-ignore-ac-events.patch +kvm-ppc-e500-mark-struct-page-dirty-in-kvmppc_e500_s.patch +kvm-ppc-e500-mark-struct-page-pfn-accessed-before-dr.patch +kvm-ppc-e500-use-__kvm_faultin_pfn-to-handle-page-fa.patch +kvm-e500-always-restore-irqs.patch +net-ncsi-add-nc-si-1.2-get-mc-mac-address-command.patch +net-ncsi-fix-locking-in-get-mac-address-handling.patch diff --git a/queue-6.6/tipc-re-order-conditions-in-tipc_crypto_key_rcv.patch b/queue-6.6/tipc-re-order-conditions-in-tipc_crypto_key_rcv.patch new file mode 100644 index 0000000000..90824f048d --- /dev/null +++ b/queue-6.6/tipc-re-order-conditions-in-tipc_crypto_key_rcv.patch @@ -0,0 +1,41 @@ +From f383e0f2f3769f24796fe7003554c3461dd8fa41 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 17 Jan 2025 12:36:14 +0300 +Subject: tipc: re-order conditions in tipc_crypto_key_rcv() + +From: Dan Carpenter + +[ Upstream commit 5fe71fda89745fc3cd95f70d06e9162b595c3702 ] + +On a 32bit system the "keylen + sizeof(struct tipc_aead_key)" math could +have an integer wrapping issue. It doesn't matter because the "keylen" +is checked on the next line, but just to make life easier for static +analysis tools, let's re-order these conditions and avoid the integer +overflow. + +Signed-off-by: Dan Carpenter +Reviewed-by: Simon Horman +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/tipc/crypto.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c +index 43c3f1c971b8f..c524421ec6525 100644 +--- a/net/tipc/crypto.c ++++ b/net/tipc/crypto.c +@@ -2293,8 +2293,8 @@ static bool tipc_crypto_key_rcv(struct tipc_crypto *rx, struct tipc_msg *hdr) + keylen = ntohl(*((__be32 *)(data + TIPC_AEAD_ALG_NAME))); + + /* Verify the supplied size values */ +- if (unlikely(size != keylen + sizeof(struct tipc_aead_key) || +- keylen > TIPC_AEAD_KEY_SIZE_MAX)) { ++ if (unlikely(keylen > TIPC_AEAD_KEY_SIZE_MAX || ++ size != keylen + sizeof(struct tipc_aead_key))) { + pr_debug("%s: invalid MSG_CRYPTO key size\n", rx->name); + goto exit; + } +-- +2.39.5 + diff --git a/queue-6.6/tomoyo-don-t-emit-warning-in-tomoyo_write_control.patch b/queue-6.6/tomoyo-don-t-emit-warning-in-tomoyo_write_control.patch new file mode 100644 index 0000000000..1b4fd9b170 --- /dev/null +++ b/queue-6.6/tomoyo-don-t-emit-warning-in-tomoyo_write_control.patch @@ -0,0 +1,46 @@ +From 43d1d344bdb8aaeb6bd09a75b3ab7e867ad02241 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 16 Dec 2024 19:38:40 +0900 +Subject: tomoyo: don't emit warning in tomoyo_write_control() + +From: Tetsuo Handa + +[ Upstream commit 3df7546fc03b8f004eee0b9e3256369f7d096685 ] + +syzbot is reporting too large allocation warning at tomoyo_write_control(), +for one can write a very very long line without new line character. To fix +this warning, I use __GFP_NOWARN rather than checking for KMALLOC_MAX_SIZE, +for practically a valid line should be always shorter than 32KB where the +"too small to fail" memory-allocation rule applies. + +One might try to write a valid line that is longer than 32KB, but such +request will likely fail with -ENOMEM. Therefore, I feel that separately +returning -EINVAL when a line is longer than KMALLOC_MAX_SIZE is redundant. +There is no need to distinguish over-32KB and over-KMALLOC_MAX_SIZE. + +Reported-by: syzbot+7536f77535e5210a5c76@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=7536f77535e5210a5c76 +Reported-by: Leo Stone +Closes: https://lkml.kernel.org/r/20241216021459.178759-2-leocstone@gmail.com +Signed-off-by: Tetsuo Handa +Signed-off-by: Sasha Levin +--- + security/tomoyo/common.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/security/tomoyo/common.c b/security/tomoyo/common.c +index ea3140d510ecb..e58e265d16578 100644 +--- a/security/tomoyo/common.c ++++ b/security/tomoyo/common.c +@@ -2665,7 +2665,7 @@ ssize_t tomoyo_write_control(struct tomoyo_io_buffer *head, + + if (head->w.avail >= head->writebuf_size - 1) { + const int len = head->writebuf_size * 2; +- char *cp = kzalloc(len, GFP_NOFS); ++ char *cp = kzalloc(len, GFP_NOFS | __GFP_NOWARN); + + if (!cp) { + error = -ENOMEM; +-- +2.39.5 + diff --git a/queue-6.6/tun-fix-group-permission-check.patch b/queue-6.6/tun-fix-group-permission-check.patch new file mode 100644 index 0000000000..b3374c982f --- /dev/null +++ b/queue-6.6/tun-fix-group-permission-check.patch @@ -0,0 +1,72 @@ +From 994f277e031be39e50ee791829536b78970399db Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 5 Dec 2024 10:36:14 +0300 +Subject: tun: fix group permission check + +From: Stas Sergeev + +[ Upstream commit 3ca459eaba1bf96a8c7878de84fa8872259a01e3 ] + +Currently tun checks the group permission even if the user have matched. +Besides going against the usual permission semantic, this has a +very interesting implication: if the tun group is not among the +supplementary groups of the tun user, then effectively no one can +access the tun device. CAP_SYS_ADMIN still can, but its the same as +not setting the tun ownership. + +This patch relaxes the group checking so that either the user match +or the group match is enough. This avoids the situation when no one +can access the device even though the ownership is properly set. + +Also I simplified the logic by removing the redundant inversions: +tun_not_capable() --> !tun_capable() + +Signed-off-by: Stas Sergeev +Reviewed-by: Willem de Bruijn +Acked-by: Jason Wang +Link: https://patch.msgid.link/20241205073614.294773-1-stsp2@yandex.ru +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/tun.c | 14 +++++++++----- + 1 file changed, 9 insertions(+), 5 deletions(-) + +diff --git a/drivers/net/tun.c b/drivers/net/tun.c +index cbb2f78ffde03..c84a749c52d12 100644 +--- a/drivers/net/tun.c ++++ b/drivers/net/tun.c +@@ -574,14 +574,18 @@ static u16 tun_select_queue(struct net_device *dev, struct sk_buff *skb, + return ret; + } + +-static inline bool tun_not_capable(struct tun_struct *tun) ++static inline bool tun_capable(struct tun_struct *tun) + { + const struct cred *cred = current_cred(); + struct net *net = dev_net(tun->dev); + +- return ((uid_valid(tun->owner) && !uid_eq(cred->euid, tun->owner)) || +- (gid_valid(tun->group) && !in_egroup_p(tun->group))) && +- !ns_capable(net->user_ns, CAP_NET_ADMIN); ++ if (ns_capable(net->user_ns, CAP_NET_ADMIN)) ++ return 1; ++ if (uid_valid(tun->owner) && uid_eq(cred->euid, tun->owner)) ++ return 1; ++ if (gid_valid(tun->group) && in_egroup_p(tun->group)) ++ return 1; ++ return 0; + } + + static void tun_set_real_num_queues(struct tun_struct *tun) +@@ -2778,7 +2782,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) + !!(tun->flags & IFF_MULTI_QUEUE)) + return -EINVAL; + +- if (tun_not_capable(tun)) ++ if (!tun_capable(tun)) + return -EPERM; + err = security_tun_dev_open(tun->security); + if (err < 0) +-- +2.39.5 + diff --git a/queue-6.6/wifi-brcmfmac-check-the-return-value-of-of_property_.patch b/queue-6.6/wifi-brcmfmac-check-the-return-value-of-of_property_.patch new file mode 100644 index 0000000000..734f7c8b87 --- /dev/null +++ b/queue-6.6/wifi-brcmfmac-check-the-return-value-of-of_property_.patch @@ -0,0 +1,87 @@ +From ee0f02f5e812ee9e94abadcdeacd50da720a5ef1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 6 Jan 2025 20:09:58 +0300 +Subject: wifi: brcmfmac: Check the return value of + of_property_read_string_index() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Stefan Dösinger + +[ Upstream commit 082d9e263af8de68f0c34f67b251818205160f6e ] + +Somewhen between 6.10 and 6.11 the driver started to crash on my +MacBookPro14,3. The property doesn't exist and 'tmp' remains +uninitialized, so we pass a random pointer to devm_kstrdup(). + +The crash I am getting looks like this: + +BUG: unable to handle page fault for address: 00007f033c669379 +PF: supervisor read access in kernel mode +PF: error_code(0x0001) - permissions violation +PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025 +Oops: Oops: 0001 [#1] SMP PTI +CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1 +Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024 +RIP: 0010:strlen+0x4/0x30 +Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc +RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202 +RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001 +RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379 +RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a +R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8 +R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30 +FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + + ? __die+0x23/0x70 + ? page_fault_oops+0x149/0x4c0 + ? raw_spin_rq_lock_nested+0xe/0x20 + ? sched_balance_newidle+0x22b/0x3c0 + ? update_load_avg+0x78/0x770 + ? exc_page_fault+0x6f/0x150 + ? asm_exc_page_fault+0x26/0x30 + ? __pfx_pci_conf1_write+0x10/0x10 + ? strlen+0x4/0x30 + devm_kstrdup+0x25/0x70 + brcmf_of_probe+0x273/0x350 [brcmfmac] + +Signed-off-by: Stefan Dösinger +Acked-by: Arend van Spriel +Signed-off-by: Kalle Valo +Link: https://patch.msgid.link/20250106170958.3595-1-stefan@codeweavers.com +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c +index 73fc701204e29..90d2c536bdaf0 100644 +--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c +@@ -96,13 +96,13 @@ void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type, + /* Set board-type to the first string of the machine compatible prop */ + root = of_find_node_by_path("/"); + if (root && err) { +- char *board_type; ++ char *board_type = NULL; + const char *tmp; + +- of_property_read_string_index(root, "compatible", 0, &tmp); +- + /* get rid of '/' in the compatible string to be able to find the FW */ +- board_type = devm_kstrdup(dev, tmp, GFP_KERNEL); ++ if (!of_property_read_string_index(root, "compatible", 0, &tmp)) ++ board_type = devm_kstrdup(dev, tmp, GFP_KERNEL); ++ + if (!board_type) { + of_node_put(root); + return; +-- +2.39.5 + diff --git a/queue-6.6/wifi-brcmsmac-add-gain-range-check-to-wlc_phy_iqcal_.patch b/queue-6.6/wifi-brcmsmac-add-gain-range-check-to-wlc_phy_iqcal_.patch new file mode 100644 index 0000000000..82e0ccd404 --- /dev/null +++ b/queue-6.6/wifi-brcmsmac-add-gain-range-check-to-wlc_phy_iqcal_.patch @@ -0,0 +1,42 @@ +From ac86cc3b3ac830a6e98e1fa9909baca54b29d78c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 10 Dec 2024 10:04:41 +0300 +Subject: wifi: brcmsmac: add gain range check to + wlc_phy_iqcal_gainparams_nphy() + +From: Dmitry Antipov + +[ Upstream commit 3f4a0948c3524ae50f166dbc6572a3296b014e62 ] + +In 'wlc_phy_iqcal_gainparams_nphy()', add gain range check to WARN() +instead of possible out-of-bounds 'tbl_iqcal_gainparams_nphy' access. +Compile tested only. + +Found by Linux Verification Center (linuxtesting.org) with SVACE. + +Signed-off-by: Dmitry Antipov +Acked-by: Arend van Spriel +Signed-off-by: Kalle Valo +Link: https://patch.msgid.link/20241210070441.836362-1-dmantipov@yandex.ru +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c +index 8580a27547891..42e7bc67e9143 100644 +--- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c ++++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c +@@ -23427,6 +23427,9 @@ wlc_phy_iqcal_gainparams_nphy(struct brcms_phy *pi, u16 core_no, + break; + } + ++ if (WARN_ON(k == NPHY_IQCAL_NUMGAINS)) ++ return; ++ + params->txgm = tbl_iqcal_gainparams_nphy[band_idx][k][1]; + params->pga = tbl_iqcal_gainparams_nphy[band_idx][k][2]; + params->pad = tbl_iqcal_gainparams_nphy[band_idx][k][3]; +-- +2.39.5 + diff --git a/queue-6.6/wifi-iwlwifi-avoid-memory-leak.patch b/queue-6.6/wifi-iwlwifi-avoid-memory-leak.patch new file mode 100644 index 0000000000..486d468a7a --- /dev/null +++ b/queue-6.6/wifi-iwlwifi-avoid-memory-leak.patch @@ -0,0 +1,69 @@ +From d6f40869123c689ece6a9dd899eca6058329b9fb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 28 Dec 2024 22:34:15 +0200 +Subject: wifi: iwlwifi: avoid memory leak + +From: Miri Korenblit + +[ Upstream commit 80e96206a3ef348fbd658d98f2f43149c36df8bc ] + +A caller of iwl_acpi_get_dsm_object must free the returned object. +iwl_acpi_get_dsm_integer returns immediately without freeing +it if the expected size is more than 8 bytes. Fix that. + +Note that with the current code this will never happen, since the caller +of iwl_acpi_get_dsm_integer already checks that the expected size if +either 1 or 4 bytes, so it can't exceed 8 bytes. + +While at it, print the DSM value instead of the return value, as this +was the intention in the first place. + +Signed-off-by: Miri Korenblit +Link: https://patch.msgid.link/20241228223206.bf61eaab99f8.Ibdc5df02f885208c222456d42c889c43b7e3b2f7@changeid +Signed-off-by: Johannes Berg +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/intel/iwlwifi/fw/acpi.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +diff --git a/drivers/net/wireless/intel/iwlwifi/fw/acpi.c b/drivers/net/wireless/intel/iwlwifi/fw/acpi.c +index 9943e2d21a8f5..e72f238ff7b23 100644 +--- a/drivers/net/wireless/intel/iwlwifi/fw/acpi.c ++++ b/drivers/net/wireless/intel/iwlwifi/fw/acpi.c +@@ -155,7 +155,7 @@ static int iwl_acpi_get_dsm_integer(struct device *dev, int rev, int func, + size_t expected_size) + { + union acpi_object *obj; +- int ret = 0; ++ int ret; + + obj = iwl_acpi_get_dsm_object(dev, rev, func, NULL, guid); + if (IS_ERR(obj)) { +@@ -170,8 +170,10 @@ static int iwl_acpi_get_dsm_integer(struct device *dev, int rev, int func, + } else if (obj->type == ACPI_TYPE_BUFFER) { + __le64 le_value = 0; + +- if (WARN_ON_ONCE(expected_size > sizeof(le_value))) +- return -EINVAL; ++ if (WARN_ON_ONCE(expected_size > sizeof(le_value))) { ++ ret = -EINVAL; ++ goto out; ++ } + + /* if the buffer size doesn't match the expected size */ + if (obj->buffer.length != expected_size) +@@ -192,8 +194,9 @@ static int iwl_acpi_get_dsm_integer(struct device *dev, int rev, int func, + } + + IWL_DEBUG_DEV_RADIO(dev, +- "ACPI: DSM method evaluated: func=%d, ret=%d\n", +- func, ret); ++ "ACPI: DSM method evaluated: func=%d, value=%lld\n", ++ func, *value); ++ ret = 0; + out: + ACPI_FREE(obj); + return ret; +-- +2.39.5 + diff --git a/queue-6.6/wifi-rtw89-add-crystal_cap-check-to-avoid-setting-as.patch b/queue-6.6/wifi-rtw89-add-crystal_cap-check-to-avoid-setting-as.patch new file mode 100644 index 0000000000..ba9cc19613 --- /dev/null +++ b/queue-6.6/wifi-rtw89-add-crystal_cap-check-to-avoid-setting-as.patch @@ -0,0 +1,81 @@ +From 12a64f5ff0768bf24424a50c9b0cbe4aabcb4394 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 28 Nov 2024 13:54:33 +0800 +Subject: wifi: rtw89: add crystal_cap check to avoid setting as overflow value + +From: Chih-Kang Chang + +[ Upstream commit 7b98caea39676561f22db58752551161bb36462b ] + +In the original flow, the crystal_cap might be calculated as a negative +value and set as an overflow value. Therefore, we added a check to limit +the calculated crystal_cap value. Additionally, we shrank the crystal_cap +adjustment according to specific CFO. + +Signed-off-by: Chih-Kang Chang +Signed-off-by: Ping-Ke Shih +Link: https://patch.msgid.link/20241128055433.11851-7-pkshih@realtek.com +Signed-off-by: Sasha Levin +--- + drivers/net/wireless/realtek/rtw89/phy.c | 11 ++++++----- + drivers/net/wireless/realtek/rtw89/phy.h | 2 +- + 2 files changed, 7 insertions(+), 6 deletions(-) + +diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c +index fac83b718a30c..457c1dd31bf9d 100644 +--- a/drivers/net/wireless/realtek/rtw89/phy.c ++++ b/drivers/net/wireless/realtek/rtw89/phy.c +@@ -2438,7 +2438,6 @@ static void rtw89_phy_cfo_set_crystal_cap(struct rtw89_dev *rtwdev, + + if (!force && cfo->crystal_cap == crystal_cap) + return; +- crystal_cap = clamp_t(u8, crystal_cap, 0, 127); + if (chip->chip_id == RTL8852A || chip->chip_id == RTL8851B) { + rtw89_phy_cfo_set_xcap_reg(rtwdev, true, crystal_cap); + rtw89_phy_cfo_set_xcap_reg(rtwdev, false, crystal_cap); +@@ -2552,7 +2551,7 @@ static void rtw89_phy_cfo_crystal_cap_adjust(struct rtw89_dev *rtwdev, + s32 curr_cfo) + { + struct rtw89_cfo_tracking_info *cfo = &rtwdev->cfo_tracking; +- s8 crystal_cap = cfo->crystal_cap; ++ int crystal_cap = cfo->crystal_cap; + s32 cfo_abs = abs(curr_cfo); + int sign; + +@@ -2569,15 +2568,17 @@ static void rtw89_phy_cfo_crystal_cap_adjust(struct rtw89_dev *rtwdev, + } + sign = curr_cfo > 0 ? 1 : -1; + if (cfo_abs > CFO_TRK_STOP_TH_4) +- crystal_cap += 7 * sign; ++ crystal_cap += 3 * sign; + else if (cfo_abs > CFO_TRK_STOP_TH_3) +- crystal_cap += 5 * sign; +- else if (cfo_abs > CFO_TRK_STOP_TH_2) + crystal_cap += 3 * sign; ++ else if (cfo_abs > CFO_TRK_STOP_TH_2) ++ crystal_cap += 1 * sign; + else if (cfo_abs > CFO_TRK_STOP_TH_1) + crystal_cap += 1 * sign; + else + return; ++ ++ crystal_cap = clamp(crystal_cap, 0, 127); + rtw89_phy_cfo_set_crystal_cap(rtwdev, (u8)crystal_cap, false); + rtw89_debug(rtwdev, RTW89_DBG_CFO, + "X_cap{Curr,Default}={0x%x,0x%x}\n", +diff --git a/drivers/net/wireless/realtek/rtw89/phy.h b/drivers/net/wireless/realtek/rtw89/phy.h +index d6dc0cbbae43b..15ed23fa4218f 100644 +--- a/drivers/net/wireless/realtek/rtw89/phy.h ++++ b/drivers/net/wireless/realtek/rtw89/phy.h +@@ -51,7 +51,7 @@ + #define CFO_TRK_STOP_TH_4 (30 << 2) + #define CFO_TRK_STOP_TH_3 (20 << 2) + #define CFO_TRK_STOP_TH_2 (10 << 2) +-#define CFO_TRK_STOP_TH_1 (00 << 2) ++#define CFO_TRK_STOP_TH_1 (03 << 2) + #define CFO_TRK_STOP_TH (2 << 2) + #define CFO_SW_COMP_FINE_TUNE (2 << 2) + #define CFO_PERIOD_CNT 15 +-- +2.39.5 + diff --git a/queue-6.6/x86-amd_nb-restrict-init-function-to-amd-based-syste.patch b/queue-6.6/x86-amd_nb-restrict-init-function-to-amd-based-syste.patch new file mode 100644 index 0000000000..e4000c20cd --- /dev/null +++ b/queue-6.6/x86-amd_nb-restrict-init-function-to-amd-based-syste.patch @@ -0,0 +1,40 @@ +From 711a69b415cb52565adb9e9cad77744d34d794e5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 6 Dec 2024 16:11:55 +0000 +Subject: x86/amd_nb: Restrict init function to AMD-based systems + +From: Yazen Ghannam + +[ Upstream commit bee9e840609cc67d0a7d82f22a2130fb7a0a766d ] + +The code implicitly operates on AMD-based systems by matching on PCI +IDs. However, the use of these IDs is going away. + +Add an explicit CPU vendor check instead of relying on PCI IDs. + +Signed-off-by: Yazen Ghannam +Signed-off-by: Borislav Petkov (AMD) +Link: https://lore.kernel.org/r/20241206161210.163701-3-yazen.ghannam@amd.com +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/amd_nb.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c +index 6dabb53f58a44..b6d5fc396f88c 100644 +--- a/arch/x86/kernel/amd_nb.c ++++ b/arch/x86/kernel/amd_nb.c +@@ -537,6 +537,10 @@ static __init void fix_erratum_688(void) + + static __init int init_amd_nbs(void) + { ++ if (boot_cpu_data.x86_vendor != X86_VENDOR_AMD && ++ boot_cpu_data.x86_vendor != X86_VENDOR_HYGON) ++ return 0; ++ + amd_cache_northbridges(); + amd_cache_gart(); + +-- +2.39.5 + diff --git a/queue-6.6/x86-kexec-allocate-pgd-for-x86_64-transition-page-ta.patch b/queue-6.6/x86-kexec-allocate-pgd-for-x86_64-transition-page-ta.patch new file mode 100644 index 0000000000..907a5013e4 --- /dev/null +++ b/queue-6.6/x86-kexec-allocate-pgd-for-x86_64-transition-page-ta.patch @@ -0,0 +1,231 @@ +From b1aa9ef1a5a74e279f5f90c901564e4586c19a6f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 5 Dec 2024 15:05:11 +0000 +Subject: x86/kexec: Allocate PGD for x86_64 transition page tables separately + +From: David Woodhouse + +[ Upstream commit 4b5bc2ec9a239bce261ffeafdd63571134102323 ] + +Now that the following fix: + + d0ceea662d45 ("x86/mm: Add _PAGE_NOPTISHADOW bit to avoid updating userspace page tables") + +stops kernel_ident_mapping_init() from scribbling over the end of a +4KiB PGD by assuming the following 4KiB will be a userspace PGD, +there's no good reason for the kexec PGD to be part of a single +8KiB allocation with the control_code_page. + +( It's not clear that that was the reason for x86_64 kexec doing it that + way in the first place either; there were no comments to that effect and + it seems to have been the case even before PTI came along. It looks like + it was just a happy accident which prevented memory corruption on kexec. ) + +Either way, it definitely isn't needed now. Just allocate the PGD +separately on x86_64, like i386 already does. + +Signed-off-by: David Woodhouse +Signed-off-by: Ingo Molnar +Cc: Baoquan He +Cc: Vivek Goyal +Cc: Dave Young +Cc: Eric Biederman +Cc: Ard Biesheuvel +Cc: "H. Peter Anvin" +Link: https://lore.kernel.org/r/20241205153343.3275139-6-dwmw2@infradead.org +Signed-off-by: Sasha Levin +--- + arch/x86/include/asm/kexec.h | 18 +++++++++--- + arch/x86/kernel/machine_kexec_64.c | 45 ++++++++++++++++-------------- + 2 files changed, 38 insertions(+), 25 deletions(-) + +diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h +index c9f6a6c5de3cf..d54dd7084a3e1 100644 +--- a/arch/x86/include/asm/kexec.h ++++ b/arch/x86/include/asm/kexec.h +@@ -16,6 +16,7 @@ + # define PAGES_NR 4 + #endif + ++# define KEXEC_CONTROL_PAGE_SIZE 4096 + # define KEXEC_CONTROL_CODE_MAX_SIZE 2048 + + #ifndef __ASSEMBLY__ +@@ -44,7 +45,6 @@ struct kimage; + /* Maximum address we can use for the control code buffer */ + # define KEXEC_CONTROL_MEMORY_LIMIT TASK_SIZE + +-# define KEXEC_CONTROL_PAGE_SIZE 4096 + + /* The native architecture */ + # define KEXEC_ARCH KEXEC_ARCH_386 +@@ -59,9 +59,6 @@ struct kimage; + /* Maximum address we can use for the control pages */ + # define KEXEC_CONTROL_MEMORY_LIMIT (MAXMEM-1) + +-/* Allocate one page for the pdp and the second for the code */ +-# define KEXEC_CONTROL_PAGE_SIZE (4096UL + 4096UL) +- + /* The native architecture */ + # define KEXEC_ARCH KEXEC_ARCH_X86_64 + #endif +@@ -146,6 +143,19 @@ struct kimage_arch { + }; + #else + struct kimage_arch { ++ /* ++ * This is a kimage control page, as it must not overlap with either ++ * source or destination address ranges. ++ */ ++ pgd_t *pgd; ++ /* ++ * The virtual mapping of the control code page itself is used only ++ * during the transition, while the current kernel's pages are all ++ * in place. Thus the intermediate page table pages used to map it ++ * are not control pages, but instead just normal pages obtained ++ * with get_zeroed_page(). And have to be tracked (below) so that ++ * they can be freed. ++ */ + p4d_t *p4d; + pud_t *pud; + pmd_t *pmd; +diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c +index 2fa12d1dc6760..8509d809a9f1b 100644 +--- a/arch/x86/kernel/machine_kexec_64.c ++++ b/arch/x86/kernel/machine_kexec_64.c +@@ -149,7 +149,8 @@ static void free_transition_pgtable(struct kimage *image) + image->arch.pte = NULL; + } + +-static int init_transition_pgtable(struct kimage *image, pgd_t *pgd) ++static int init_transition_pgtable(struct kimage *image, pgd_t *pgd, ++ unsigned long control_page) + { + pgprot_t prot = PAGE_KERNEL_EXEC_NOENC; + unsigned long vaddr, paddr; +@@ -160,7 +161,7 @@ static int init_transition_pgtable(struct kimage *image, pgd_t *pgd) + pte_t *pte; + + vaddr = (unsigned long)relocate_kernel; +- paddr = __pa(page_address(image->control_code_page)+PAGE_SIZE); ++ paddr = control_page; + pgd += pgd_index(vaddr); + if (!pgd_present(*pgd)) { + p4d = (p4d_t *)get_zeroed_page(GFP_KERNEL); +@@ -219,7 +220,7 @@ static void *alloc_pgt_page(void *data) + return p; + } + +-static int init_pgtable(struct kimage *image, unsigned long start_pgtable) ++static int init_pgtable(struct kimage *image, unsigned long control_page) + { + struct x86_mapping_info info = { + .alloc_pgt_page = alloc_pgt_page, +@@ -228,12 +229,12 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) + .kernpg_flag = _KERNPG_TABLE_NOENC, + }; + unsigned long mstart, mend; +- pgd_t *level4p; + int result; + int i; + +- level4p = (pgd_t *)__va(start_pgtable); +- clear_page(level4p); ++ image->arch.pgd = alloc_pgt_page(image); ++ if (!image->arch.pgd) ++ return -ENOMEM; + + if (cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) { + info.page_flag |= _PAGE_ENC; +@@ -247,8 +248,8 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) + mstart = pfn_mapped[i].start << PAGE_SHIFT; + mend = pfn_mapped[i].end << PAGE_SHIFT; + +- result = kernel_ident_mapping_init(&info, +- level4p, mstart, mend); ++ result = kernel_ident_mapping_init(&info, image->arch.pgd, ++ mstart, mend); + if (result) + return result; + } +@@ -263,8 +264,8 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) + mstart = image->segment[i].mem; + mend = mstart + image->segment[i].memsz; + +- result = kernel_ident_mapping_init(&info, +- level4p, mstart, mend); ++ result = kernel_ident_mapping_init(&info, image->arch.pgd, ++ mstart, mend); + + if (result) + return result; +@@ -274,15 +275,19 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) + * Prepare EFI systab and ACPI tables for kexec kernel since they are + * not covered by pfn_mapped. + */ +- result = map_efi_systab(&info, level4p); ++ result = map_efi_systab(&info, image->arch.pgd); + if (result) + return result; + +- result = map_acpi_tables(&info, level4p); ++ result = map_acpi_tables(&info, image->arch.pgd); + if (result) + return result; + +- return init_transition_pgtable(image, level4p); ++ /* ++ * This must be last because the intermediate page table pages it ++ * allocates will not be control pages and may overlap the image. ++ */ ++ return init_transition_pgtable(image, image->arch.pgd, control_page); + } + + static void load_segments(void) +@@ -299,14 +304,14 @@ static void load_segments(void) + + int machine_kexec_prepare(struct kimage *image) + { +- unsigned long start_pgtable; ++ unsigned long control_page; + int result; + + /* Calculate the offsets */ +- start_pgtable = page_to_pfn(image->control_code_page) << PAGE_SHIFT; ++ control_page = page_to_pfn(image->control_code_page) << PAGE_SHIFT; + + /* Setup the identity mapped 64bit page table */ +- result = init_pgtable(image, start_pgtable); ++ result = init_pgtable(image, control_page); + if (result) + return result; + +@@ -360,13 +365,12 @@ void machine_kexec(struct kimage *image) + #endif + } + +- control_page = page_address(image->control_code_page) + PAGE_SIZE; ++ control_page = page_address(image->control_code_page); + __memcpy(control_page, relocate_kernel, KEXEC_CONTROL_CODE_MAX_SIZE); + + page_list[PA_CONTROL_PAGE] = virt_to_phys(control_page); + page_list[VA_CONTROL_PAGE] = (unsigned long)control_page; +- page_list[PA_TABLE_PAGE] = +- (unsigned long)__pa(page_address(image->control_code_page)); ++ page_list[PA_TABLE_PAGE] = (unsigned long)__pa(image->arch.pgd); + + if (image->type == KEXEC_TYPE_DEFAULT) + page_list[PA_SWAP_PAGE] = (page_to_pfn(image->swap_page) +@@ -574,8 +578,7 @@ static void kexec_mark_crashkres(bool protect) + + /* Don't touch the control code page used in crash_kexec().*/ + control = PFN_PHYS(page_to_pfn(kexec_crash_image->control_code_page)); +- /* Control code page is located in the 2nd page. */ +- kexec_mark_range(crashk_res.start, control + PAGE_SIZE - 1, protect); ++ kexec_mark_range(crashk_res.start, control - 1, protect); + control += KEXEC_CONTROL_PAGE_SIZE; + kexec_mark_range(control, crashk_res.end, protect); + } +-- +2.39.5 +