From: Sasha Levin Date: Wed, 6 Nov 2024 01:54:05 +0000 (-0500) Subject: Fixes for 6.6 X-Git-Tag: v4.19.323~58 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c648bbc6e1ffa98eaac1daec8cb5a9905bbcb2cc;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 6.6 Signed-off-by: Sasha Levin --- diff --git a/queue-6.6/alsa-hda-realtek-fix-headset-mic-on-tuxedo-gemini-17.patch b/queue-6.6/alsa-hda-realtek-fix-headset-mic-on-tuxedo-gemini-17.patch new file mode 100644 index 00000000000..be16987e955 --- /dev/null +++ b/queue-6.6/alsa-hda-realtek-fix-headset-mic-on-tuxedo-gemini-17.patch @@ -0,0 +1,36 @@ +From 85935540e709beb1b8da3eaaf616c5ca0429a5ff Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 29 Oct 2024 16:16:52 +0100 +Subject: ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3 + +From: Christoffer Sandberg + +[ Upstream commit 0b04fbe886b4274c8e5855011233aaa69fec6e75 ] + +Quirk is needed to enable headset microphone on missing pin 0x19. + +Signed-off-by: Christoffer Sandberg +Signed-off-by: Werner Sembach +Cc: +Link: https://patch.msgid.link/20241029151653.80726-1-wse@tuxedocomputers.com +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/patch_realtek.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c +index bf504744ae2a3..62747d77cd9ab 100644 +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -10182,6 +10182,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { + SND_PCI_QUIRK(0x1558, 0x1404, "Clevo N150CU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1558, 0x14a1, "Clevo L141MU", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1558, 0x2624, "Clevo L240TU", ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE), ++ SND_PCI_QUIRK(0x1558, 0x28c1, "Clevo V370VND", ALC2XX_FIXUP_HEADSET_MIC), + SND_PCI_QUIRK(0x1558, 0x4018, "Clevo NV40M[BE]", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1558, 0x4019, "Clevo NV40MZ", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1558, 0x4020, "Clevo NV40MB", ALC293_FIXUP_SYSTEM76_MIC_NO_PRESENCE), +-- +2.43.0 + diff --git a/queue-6.6/alsa-hda-realtek-fix-headset-mic-on-tuxedo-stellaris.patch b/queue-6.6/alsa-hda-realtek-fix-headset-mic-on-tuxedo-stellaris.patch new file mode 100644 index 00000000000..3e01ad69dab --- /dev/null +++ b/queue-6.6/alsa-hda-realtek-fix-headset-mic-on-tuxedo-stellaris.patch @@ -0,0 +1,36 @@ +From 593558b2ebd053fa6fc5aa4724a856da18681c0d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 29 Oct 2024 16:16:53 +0100 +Subject: ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1 + +From: Christoffer Sandberg + +[ Upstream commit e49370d769e71456db3fbd982e95bab8c69f73e8 ] + +Quirk is needed to enable headset microphone on missing pin 0x19. + +Signed-off-by: Christoffer Sandberg +Signed-off-by: Werner Sembach +Cc: +Link: https://patch.msgid.link/20241029151653.80726-2-wse@tuxedocomputers.com +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/patch_realtek.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c +index 62747d77cd9ab..3c48036fdf0b0 100644 +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -10403,6 +10403,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { + SND_PCI_QUIRK(0x1d05, 0x115c, "TongFang GMxTGxx", ALC269_FIXUP_NO_SHUTUP), + SND_PCI_QUIRK(0x1d05, 0x121b, "TongFang GMxAGxx", ALC269_FIXUP_NO_SHUTUP), + SND_PCI_QUIRK(0x1d05, 0x1387, "TongFang GMxIXxx", ALC2XX_FIXUP_HEADSET_MIC), ++ SND_PCI_QUIRK(0x1d05, 0x1409, "TongFang GMxIXxx", ALC2XX_FIXUP_HEADSET_MIC), + SND_PCI_QUIRK(0x1d17, 0x3288, "Haier Boyue G42", ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS), + SND_PCI_QUIRK(0x1d72, 0x1602, "RedmiBook", ALC255_FIXUP_XIAOMI_HEADSET_MIC), + SND_PCI_QUIRK(0x1d72, 0x1701, "XiaomiNotebook Pro", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE), +-- +2.43.0 + diff --git a/queue-6.6/alsa-hda-realtek-limit-internal-mic-boost-on-dell-pl.patch b/queue-6.6/alsa-hda-realtek-limit-internal-mic-boost-on-dell-pl.patch new file mode 100644 index 00000000000..9b440b8e458 --- /dev/null +++ b/queue-6.6/alsa-hda-realtek-limit-internal-mic-boost-on-dell-pl.patch @@ -0,0 +1,97 @@ +From 8cf55c09a70824af860b3fd6e384425f07a2247e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 18 Oct 2024 13:53:24 +0800 +Subject: ALSA: hda/realtek: Limit internal Mic boost on Dell platform + +From: Kailang Yang + +[ Upstream commit 78e7be018784934081afec77f96d49a2483f9188 ] + +Dell want to limit internal Mic boost on all Dell platform. + +Signed-off-by: Kailang Yang +Cc: +Link: https://lore.kernel.org/561fc5f5eff04b6cbd79ed173cd1c1db@realtek.com +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + sound/pci/hda/patch_realtek.c | 21 ++++++++++++++++++--- + 1 file changed, 18 insertions(+), 3 deletions(-) + +diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c +index 9be5a5c509f09..bf504744ae2a3 100644 +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -7234,6 +7234,7 @@ enum { + ALC286_FIXUP_SONY_MIC_NO_PRESENCE, + ALC269_FIXUP_PINCFG_NO_HP_TO_LINEOUT, + ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, ++ ALC269_FIXUP_DELL1_LIMIT_INT_MIC_BOOST, + ALC269_FIXUP_DELL2_MIC_NO_PRESENCE, + ALC269_FIXUP_DELL3_MIC_NO_PRESENCE, + ALC269_FIXUP_DELL4_MIC_NO_PRESENCE, +@@ -7268,6 +7269,7 @@ enum { + ALC255_FIXUP_ACER_MIC_NO_PRESENCE, + ALC255_FIXUP_ASUS_MIC_NO_PRESENCE, + ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ++ ALC255_FIXUP_DELL1_LIMIT_INT_MIC_BOOST, + ALC255_FIXUP_DELL2_MIC_NO_PRESENCE, + ALC255_FIXUP_HEADSET_MODE, + ALC255_FIXUP_HEADSET_MODE_NO_HP_MIC, +@@ -7760,6 +7762,12 @@ static const struct hda_fixup alc269_fixups[] = { + .chained = true, + .chain_id = ALC269_FIXUP_HEADSET_MODE + }, ++ [ALC269_FIXUP_DELL1_LIMIT_INT_MIC_BOOST] = { ++ .type = HDA_FIXUP_FUNC, ++ .v.func = alc269_fixup_limit_int_mic_boost, ++ .chained = true, ++ .chain_id = ALC269_FIXUP_DELL1_MIC_NO_PRESENCE ++ }, + [ALC269_FIXUP_DELL2_MIC_NO_PRESENCE] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { +@@ -8040,6 +8048,12 @@ static const struct hda_fixup alc269_fixups[] = { + .chained = true, + .chain_id = ALC255_FIXUP_HEADSET_MODE + }, ++ [ALC255_FIXUP_DELL1_LIMIT_INT_MIC_BOOST] = { ++ .type = HDA_FIXUP_FUNC, ++ .v.func = alc269_fixup_limit_int_mic_boost, ++ .chained = true, ++ .chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE ++ }, + [ALC255_FIXUP_DELL2_MIC_NO_PRESENCE] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { +@@ -10482,6 +10496,7 @@ static const struct hda_model_fixup alc269_fixup_models[] = { + {.id = ALC269_FIXUP_DELL2_MIC_NO_PRESENCE, .name = "dell-headset-dock"}, + {.id = ALC269_FIXUP_DELL3_MIC_NO_PRESENCE, .name = "dell-headset3"}, + {.id = ALC269_FIXUP_DELL4_MIC_NO_PRESENCE, .name = "dell-headset4"}, ++ {.id = ALC269_FIXUP_DELL4_MIC_NO_PRESENCE_QUIET, .name = "dell-headset4-quiet"}, + {.id = ALC283_FIXUP_CHROME_BOOK, .name = "alc283-dac-wcaps"}, + {.id = ALC283_FIXUP_SENSE_COMBO_JACK, .name = "alc283-sense-combo"}, + {.id = ALC292_FIXUP_TPT440_DOCK, .name = "tpt440-dock"}, +@@ -11033,16 +11048,16 @@ static const struct snd_hda_pin_quirk alc269_fallback_pin_fixup_tbl[] = { + SND_HDA_PIN_QUIRK(0x10ec0289, 0x1028, "Dell", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE, + {0x19, 0x40000000}, + {0x1b, 0x40000000}), +- SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE, ++ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL4_MIC_NO_PRESENCE_QUIET, + {0x19, 0x40000000}, + {0x1b, 0x40000000}), + SND_HDA_PIN_QUIRK(0x10ec0256, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x19, 0x40000000}, + {0x1a, 0x40000000}), +- SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ++ SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", ALC255_FIXUP_DELL1_LIMIT_INT_MIC_BOOST, + {0x19, 0x40000000}, + {0x1a, 0x40000000}), +- SND_HDA_PIN_QUIRK(0x10ec0274, 0x1028, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB, ++ SND_HDA_PIN_QUIRK(0x10ec0274, 0x1028, "Dell", ALC269_FIXUP_DELL1_LIMIT_INT_MIC_BOOST, + {0x19, 0x40000000}, + {0x1a, 0x40000000}), + SND_HDA_PIN_QUIRK(0x10ec0256, 0x1043, "ASUS", ALC2XX_FIXUP_HEADSET_MIC, +-- +2.43.0 + diff --git a/queue-6.6/block-fix-sanity-checks-in-blk_rq_map_user_bvec.patch b/queue-6.6/block-fix-sanity-checks-in-blk_rq_map_user_bvec.patch new file mode 100644 index 00000000000..f4a04e1cf24 --- /dev/null +++ b/queue-6.6/block-fix-sanity-checks-in-blk_rq_map_user_bvec.patch @@ -0,0 +1,59 @@ +From c0f268e3d2262dd28f14dbf293b769f6ae09625f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 23 Oct 2024 15:15:19 -0600 +Subject: block: fix sanity checks in blk_rq_map_user_bvec + +From: Xinyu Zhang + +[ Upstream commit 2ff949441802a8d076d9013c7761f63e8ae5a9bd ] + +blk_rq_map_user_bvec contains a check bytes + bv->bv_len > nr_iter which +causes unnecessary failures in NVMe passthrough I/O, reproducible as +follows: + +- register a 2 page, page-aligned buffer against a ring +- use that buffer to do a 1 page io_uring NVMe passthrough read + +The second (i = 1) iteration of the loop in blk_rq_map_user_bvec will +then have nr_iter == 1 page, bytes == 1 page, bv->bv_len == 1 page, so +the check bytes + bv->bv_len > nr_iter will succeed, causing the I/O to +fail. This failure is unnecessary, as when the check succeeds, it means +we've checked the entire buffer that will be used by the request - i.e. +blk_rq_map_user_bvec should complete successfully. Therefore, terminate +the loop early and return successfully when the check bytes + bv->bv_len +> nr_iter succeeds. + +While we're at it, also remove the check that all segments in the bvec +are single-page. While this seems to be true for all users of the +function, it doesn't appear to be required anywhere downstream. + +CC: stable@vger.kernel.org +Signed-off-by: Xinyu Zhang +Co-developed-by: Uday Shankar +Signed-off-by: Uday Shankar +Fixes: 37987547932c ("block: extend functionality to map bvec iterator") +Link: https://lore.kernel.org/r/20241023211519.4177873-1-ushankar@purestorage.com +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + block/blk-map.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +diff --git a/block/blk-map.c b/block/blk-map.c +index 71210cdb34426..0aadbaf7a9ddd 100644 +--- a/block/blk-map.c ++++ b/block/blk-map.c +@@ -600,9 +600,7 @@ static int blk_rq_map_user_bvec(struct request *rq, const struct iov_iter *iter) + if (nsegs >= nr_segs || bytes > UINT_MAX - bv->bv_len) + goto put_bio; + if (bytes + bv->bv_len > nr_iter) +- goto put_bio; +- if (bv->bv_offset + bv->bv_len > PAGE_SIZE) +- goto put_bio; ++ break; + + nsegs++; + bytes += bv->bv_len; +-- +2.43.0 + diff --git a/queue-6.6/cgroup-bpf-use-a-dedicated-workqueue-for-cgroup-bpf-.patch b/queue-6.6/cgroup-bpf-use-a-dedicated-workqueue-for-cgroup-bpf-.patch new file mode 100644 index 00000000000..a86991c1788 --- /dev/null +++ b/queue-6.6/cgroup-bpf-use-a-dedicated-workqueue-for-cgroup-bpf-.patch @@ -0,0 +1,154 @@ +From 1f2241d47fb93c03f32494036c38b066e727cb9a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 11:24:56 +0000 +Subject: cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction + +From: Chen Ridong + +[ Upstream commit 117932eea99b729ee5d12783601a4f7f5fd58a23 ] + +A hung_task problem shown below was found: + +INFO: task kworker/0:0:8 blocked for more than 327 seconds. +"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. +Workqueue: events cgroup_bpf_release +Call Trace: + + __schedule+0x5a2/0x2050 + ? find_held_lock+0x33/0x100 + ? wq_worker_sleeping+0x9e/0xe0 + schedule+0x9f/0x180 + schedule_preempt_disabled+0x25/0x50 + __mutex_lock+0x512/0x740 + ? cgroup_bpf_release+0x1e/0x4d0 + ? cgroup_bpf_release+0xcf/0x4d0 + ? process_scheduled_works+0x161/0x8a0 + ? cgroup_bpf_release+0x1e/0x4d0 + ? mutex_lock_nested+0x2b/0x40 + ? __pfx_delay_tsc+0x10/0x10 + mutex_lock_nested+0x2b/0x40 + cgroup_bpf_release+0xcf/0x4d0 + ? process_scheduled_works+0x161/0x8a0 + ? trace_event_raw_event_workqueue_execute_start+0x64/0xd0 + ? process_scheduled_works+0x161/0x8a0 + process_scheduled_works+0x23a/0x8a0 + worker_thread+0x231/0x5b0 + ? __pfx_worker_thread+0x10/0x10 + kthread+0x14d/0x1c0 + ? __pfx_kthread+0x10/0x10 + ret_from_fork+0x59/0x70 + ? __pfx_kthread+0x10/0x10 + ret_from_fork_asm+0x1b/0x30 + + +This issue can be reproduced by the following pressuse test: +1. A large number of cpuset cgroups are deleted. +2. Set cpu on and off repeatly. +3. Set watchdog_thresh repeatly. +The scripts can be obtained at LINK mentioned above the signature. + +The reason for this issue is cgroup_mutex and cpu_hotplug_lock are +acquired in different tasks, which may lead to deadlock. +It can lead to a deadlock through the following steps: +1. A large number of cpusets are deleted asynchronously, which puts a + large number of cgroup_bpf_release works into system_wq. The max_active + of system_wq is WQ_DFL_ACTIVE(256). Consequently, all active works are + cgroup_bpf_release works, and many cgroup_bpf_release works will be put + into inactive queue. As illustrated in the diagram, there are 256 (in + the acvtive queue) + n (in the inactive queue) works. +2. Setting watchdog_thresh will hold cpu_hotplug_lock.read and put + smp_call_on_cpu work into system_wq. However step 1 has already filled + system_wq, 'sscs.work' is put into inactive queue. 'sscs.work' has + to wait until the works that were put into the inacvtive queue earlier + have executed (n cgroup_bpf_release), so it will be blocked for a while. +3. Cpu offline requires cpu_hotplug_lock.write, which is blocked by step 2. +4. Cpusets that were deleted at step 1 put cgroup_release works into + cgroup_destroy_wq. They are competing to get cgroup_mutex all the time. + When cgroup_metux is acqured by work at css_killed_work_fn, it will + call cpuset_css_offline, which needs to acqure cpu_hotplug_lock.read. + However, cpuset_css_offline will be blocked for step 3. +5. At this moment, there are 256 works in active queue that are + cgroup_bpf_release, they are attempting to acquire cgroup_mutex, and as + a result, all of them are blocked. Consequently, sscs.work can not be + executed. Ultimately, this situation leads to four processes being + blocked, forming a deadlock. + +system_wq(step1) WatchDog(step2) cpu offline(step3) cgroup_destroy_wq(step4) +... +2000+ cgroups deleted asyn +256 actives + n inactives + __lockup_detector_reconfigure + P(cpu_hotplug_lock.read) + put sscs.work into system_wq +256 + n + 1(sscs.work) +sscs.work wait to be executed + warting sscs.work finish + percpu_down_write + P(cpu_hotplug_lock.write) + ...blocking... + css_killed_work_fn + P(cgroup_mutex) + cpuset_css_offline + P(cpu_hotplug_lock.read) + ...blocking... +256 cgroup_bpf_release +mutex_lock(&cgroup_mutex); +..blocking... + +To fix the problem, place cgroup_bpf_release works on a dedicated +workqueue which can break the loop and solve the problem. System wqs are +for misc things which shouldn't create a large number of concurrent work +items. If something is going to generate >WQ_DFL_ACTIVE(256) concurrent +work items, it should use its own dedicated workqueue. + +Fixes: 4bfc0bb2c60e ("bpf: decouple the lifetime of cgroup_bpf from cgroup itself") +Cc: stable@vger.kernel.org # v5.3+ +Link: https://lore.kernel.org/cgroups/e90c32d2-2a85-4f28-9154-09c7d320cb60@huawei.com/T/#t +Tested-by: Vishal Chourasia +Signed-off-by: Chen Ridong +Signed-off-by: Tejun Heo +Signed-off-by: Sasha Levin +--- + kernel/bpf/cgroup.c | 19 ++++++++++++++++++- + 1 file changed, 18 insertions(+), 1 deletion(-) + +diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c +index 913a6a7e62ca6..cf2eb0895d403 100644 +--- a/kernel/bpf/cgroup.c ++++ b/kernel/bpf/cgroup.c +@@ -24,6 +24,23 @@ + DEFINE_STATIC_KEY_ARRAY_FALSE(cgroup_bpf_enabled_key, MAX_CGROUP_BPF_ATTACH_TYPE); + EXPORT_SYMBOL(cgroup_bpf_enabled_key); + ++/* ++ * cgroup bpf destruction makes heavy use of work items and there can be a lot ++ * of concurrent destructions. Use a separate workqueue so that cgroup bpf ++ * destruction work items don't end up filling up max_active of system_wq ++ * which may lead to deadlock. ++ */ ++static struct workqueue_struct *cgroup_bpf_destroy_wq; ++ ++static int __init cgroup_bpf_wq_init(void) ++{ ++ cgroup_bpf_destroy_wq = alloc_workqueue("cgroup_bpf_destroy", 0, 1); ++ if (!cgroup_bpf_destroy_wq) ++ panic("Failed to alloc workqueue for cgroup bpf destroy.\n"); ++ return 0; ++} ++core_initcall(cgroup_bpf_wq_init); ++ + /* __always_inline is necessary to prevent indirect call through run_prog + * function pointer. + */ +@@ -334,7 +351,7 @@ static void cgroup_bpf_release_fn(struct percpu_ref *ref) + struct cgroup *cgrp = container_of(ref, struct cgroup, bpf.refcnt); + + INIT_WORK(&cgrp->bpf.release_work, cgroup_bpf_release); +- queue_work(system_wq, &cgrp->bpf.release_work); ++ queue_work(cgroup_bpf_destroy_wq, &cgrp->bpf.release_work); + } + + /* Get underlying bpf_prog of bpf_prog_list entry, regardless if it's through +-- +2.43.0 + diff --git a/queue-6.6/cxl-acpi-ensure-ports-ready-at-cxl_acpi_probe-return.patch b/queue-6.6/cxl-acpi-ensure-ports-ready-at-cxl_acpi_probe-return.patch new file mode 100644 index 00000000000..5c4158feedb --- /dev/null +++ b/queue-6.6/cxl-acpi-ensure-ports-ready-at-cxl_acpi_probe-return.patch @@ -0,0 +1,52 @@ +From 530a15ffaca9805f0b9ae77f132b9ab0b9ded5c6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Oct 2024 18:43:40 -0700 +Subject: cxl/acpi: Ensure ports ready at cxl_acpi_probe() return + +From: Dan Williams + +[ Upstream commit 48f62d38a07d464a499fa834638afcfd2b68f852 ] + +In order to ensure root CXL ports are enabled upon cxl_acpi_probe() +when the 'cxl_port' driver is built as a module, arrange for the +module to be pre-loaded or built-in. + +The "Fixes:" but no "Cc: stable" on this patch reflects that the issue +is merely by inspection since the bug that triggered the discovery of +this potential problem [1] is fixed by other means. However, a stable +backport should do no harm. + +Fixes: 8dd2bc0f8e02 ("cxl/mem: Add the cxl_mem driver") +Link: http://lore.kernel.org/20241004212504.1246-1-gourry@gourry.net [1] +Signed-off-by: Dan Williams +Tested-by: Gregory Price +Reviewed-by: Jonathan Cameron +Reviewed-by: Ira Weiny +Link: https://patch.msgid.link/172964781969.81806.17276352414854540808.stgit@dwillia2-xfh.jf.intel.com +Signed-off-by: Ira Weiny +Signed-off-by: Sasha Levin +--- + drivers/cxl/acpi.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c +index 4319534558309..9a881a764cf35 100644 +--- a/drivers/cxl/acpi.c ++++ b/drivers/cxl/acpi.c +@@ -768,6 +768,13 @@ static void __exit cxl_acpi_exit(void) + + /* load before dax_hmem sees 'Soft Reserved' CXL ranges */ + subsys_initcall(cxl_acpi_init); ++ ++/* ++ * Arrange for host-bridge ports to be active synchronous with ++ * cxl_acpi_probe() exit. ++ */ ++MODULE_SOFTDEP("pre: cxl_port"); ++ + module_exit(cxl_acpi_exit); + MODULE_LICENSE("GPL v2"); + MODULE_IMPORT_NS(CXL); +-- +2.43.0 + diff --git a/queue-6.6/cxl-port-fix-cxl_bus_rescan-vs-bus_rescan_devices.patch b/queue-6.6/cxl-port-fix-cxl_bus_rescan-vs-bus_rescan_devices.patch new file mode 100644 index 00000000000..b5638e54c38 --- /dev/null +++ b/queue-6.6/cxl-port-fix-cxl_bus_rescan-vs-bus_rescan_devices.patch @@ -0,0 +1,65 @@ +From f268ae3a55a22ebf43335f9e75843e55e01d9ea8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Oct 2024 18:43:32 -0700 +Subject: cxl/port: Fix cxl_bus_rescan() vs bus_rescan_devices() + +From: Dan Williams + +[ Upstream commit 3d6ebf16438de5d712030fefbb4182b46373d677 ] + +It turns out since its original introduction, pre-2.6.12, +bus_rescan_devices() has skipped devices that might be in the process of +attaching or detaching from their driver. For CXL this behavior is +unwanted and expects that cxl_bus_rescan() is a probe barrier. + +That behavior is simple enough to achieve with bus_for_each_dev() paired +with call to device_attach(), and it is unclear why bus_rescan_devices() +took the position of lockless consumption of dev->driver which is racy. + +The "Fixes:" but no "Cc: stable" on this patch reflects that the issue +is merely by inspection since the bug that triggered the discovery of +this potential problem [1] is fixed by other means. However, a stable +backport should do no harm. + +Fixes: 8dd2bc0f8e02 ("cxl/mem: Add the cxl_mem driver") +Link: http://lore.kernel.org/20241004212504.1246-1-gourry@gourry.net [1] +Signed-off-by: Dan Williams +Tested-by: Gregory Price +Reviewed-by: Jonathan Cameron +Reviewed-by: Ira Weiny +Link: https://patch.msgid.link/172964781104.81806.4277549800082443769.stgit@dwillia2-xfh.jf.intel.com +Signed-off-by: Ira Weiny +Signed-off-by: Sasha Levin +--- + drivers/cxl/core/port.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +diff --git a/drivers/cxl/core/port.c b/drivers/cxl/core/port.c +index c67cc8c9d5cc6..7f28d1021fa99 100644 +--- a/drivers/cxl/core/port.c ++++ b/drivers/cxl/core/port.c +@@ -1969,11 +1969,18 @@ static void cxl_bus_remove(struct device *dev) + + static struct workqueue_struct *cxl_bus_wq; + +-static void cxl_bus_rescan_queue(struct work_struct *w) ++static int cxl_rescan_attach(struct device *dev, void *data) + { +- int rc = bus_rescan_devices(&cxl_bus_type); ++ int rc = device_attach(dev); ++ ++ dev_vdbg(dev, "rescan: %s\n", rc ? "attach" : "detached"); + +- pr_debug("CXL bus rescan result: %d\n", rc); ++ return 0; ++} ++ ++static void cxl_bus_rescan_queue(struct work_struct *w) ++{ ++ bus_for_each_dev(&cxl_bus_type, NULL, NULL, cxl_rescan_attach); + } + + void cxl_bus_rescan(void) +-- +2.43.0 + diff --git a/queue-6.6/input-edt-ft5x06-fix-regmap-leak-when-probe-fails.patch b/queue-6.6/input-edt-ft5x06-fix-regmap-leak-when-probe-fails.patch new file mode 100644 index 00000000000..e12e9ea8c17 --- /dev/null +++ b/queue-6.6/input-edt-ft5x06-fix-regmap-leak-when-probe-fails.patch @@ -0,0 +1,82 @@ +From 94c34c17e790d3ca21ba232057b71b14d7322b27 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 18 Oct 2024 17:17:48 -0700 +Subject: Input: edt-ft5x06 - fix regmap leak when probe fails + +From: Dmitry Torokhov + +[ Upstream commit bffdf9d7e51a7be8eeaac2ccf9e54a5fde01ff65 ] + +The driver neglects to free the instance of I2C regmap constructed at +the beginning of the edt_ft5x06_ts_probe() method when probe fails. +Additionally edt_ft5x06_ts_remove() is freeing the regmap too early, +before the rest of the device resources that are managed by devm are +released. + +Fix this by installing a custom devm action that will ensure that the +regmap is released at the right time during normal teardown as well as +in case of probe failure. + +Note that devm_regmap_init_i2c() could not be used because the driver +may replace the original regmap with a regmap specific for M06 devices +in the middle of the probe, and using devm_regmap_init_i2c() would +result in releasing the M06 regmap too early. + +Reported-by: Li Zetao +Fixes: 9dfd9708ffba ("Input: edt-ft5x06 - convert to use regmap API") +Cc: stable@vger.kernel.org +Reviewed-by: Oliver Graute +Link: https://lore.kernel.org/r/ZxL6rIlVlgsAu-Jv@google.com +Signed-off-by: Dmitry Torokhov +Signed-off-by: Sasha Levin +--- + drivers/input/touchscreen/edt-ft5x06.c | 19 ++++++++++++++++++- + 1 file changed, 18 insertions(+), 1 deletion(-) + +diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c +index 457d53337fbb3..a365577a19945 100644 +--- a/drivers/input/touchscreen/edt-ft5x06.c ++++ b/drivers/input/touchscreen/edt-ft5x06.c +@@ -1124,6 +1124,14 @@ static void edt_ft5x06_ts_set_regs(struct edt_ft5x06_ts_data *tsdata) + } + } + ++static void edt_ft5x06_exit_regmap(void *arg) ++{ ++ struct edt_ft5x06_ts_data *data = arg; ++ ++ if (!IS_ERR_OR_NULL(data->regmap)) ++ regmap_exit(data->regmap); ++} ++ + static void edt_ft5x06_disable_regulators(void *arg) + { + struct edt_ft5x06_ts_data *data = arg; +@@ -1157,6 +1165,16 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client) + return PTR_ERR(tsdata->regmap); + } + ++ /* ++ * We are not using devm_regmap_init_i2c() and instead install a ++ * custom action because we may replace regmap with M06-specific one ++ * and we need to make sure that it will not be released too early. ++ */ ++ error = devm_add_action_or_reset(&client->dev, edt_ft5x06_exit_regmap, ++ tsdata); ++ if (error) ++ return error; ++ + chip_data = device_get_match_data(&client->dev); + if (!chip_data) + chip_data = (const struct edt_i2c_chip_data *)id->driver_data; +@@ -1354,7 +1372,6 @@ static void edt_ft5x06_ts_remove(struct i2c_client *client) + struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client); + + edt_ft5x06_ts_teardown_debugfs(tsdata); +- regmap_exit(tsdata->regmap); + } + + static int edt_ft5x06_ts_suspend(struct device *dev) +-- +2.43.0 + diff --git a/queue-6.6/io_uring-rw-fix-missing-nowait-check-for-o_direct-st.patch b/queue-6.6/io_uring-rw-fix-missing-nowait-check-for-o_direct-st.patch new file mode 100644 index 00000000000..b0ffafa1231 --- /dev/null +++ b/queue-6.6/io_uring-rw-fix-missing-nowait-check-for-o_direct-st.patch @@ -0,0 +1,121 @@ +From 596ef9d823b54cc47a66beb1e2a6e1cdd96835ca Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 31 Oct 2024 08:05:44 -0600 +Subject: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write + +From: Jens Axboe + +[ Upstream commit 1d60d74e852647255bd8e76f5a22dc42531e4389 ] + +When io_uring starts a write, it'll call kiocb_start_write() to bump the +super block rwsem, preventing any freezes from happening while that +write is in-flight. The freeze side will grab that rwsem for writing, +excluding any new writers from happening and waiting for existing writes +to finish. But io_uring unconditionally uses kiocb_start_write(), which +will block if someone is currently attempting to freeze the mount point. +This causes a deadlock where freeze is waiting for previous writes to +complete, but the previous writes cannot complete, as the task that is +supposed to complete them is blocked waiting on starting a new write. +This results in the following stuck trace showing that dependency with +the write blocked starting a new write: + +task:fio state:D stack:0 pid:886 tgid:886 ppid:876 +Call trace: + __switch_to+0x1d8/0x348 + __schedule+0x8e8/0x2248 + schedule+0x110/0x3f0 + percpu_rwsem_wait+0x1e8/0x3f8 + __percpu_down_read+0xe8/0x500 + io_write+0xbb8/0xff8 + io_issue_sqe+0x10c/0x1020 + io_submit_sqes+0x614/0x2110 + __arm64_sys_io_uring_enter+0x524/0x1038 + invoke_syscall+0x74/0x268 + el0_svc_common.constprop.0+0x160/0x238 + do_el0_svc+0x44/0x60 + el0_svc+0x44/0xb0 + el0t_64_sync_handler+0x118/0x128 + el0t_64_sync+0x168/0x170 +INFO: task fsfreeze:7364 blocked for more than 15 seconds. + Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 + +with the attempting freezer stuck trying to grab the rwsem: + +task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 +Call trace: + __switch_to+0x1d8/0x348 + __schedule+0x8e8/0x2248 + schedule+0x110/0x3f0 + percpu_down_write+0x2b0/0x680 + freeze_super+0x248/0x8a8 + do_vfs_ioctl+0x149c/0x1b18 + __arm64_sys_ioctl+0xd0/0x1a0 + invoke_syscall+0x74/0x268 + el0_svc_common.constprop.0+0x160/0x238 + do_el0_svc+0x44/0x60 + el0_svc+0x44/0xb0 + el0t_64_sync_handler+0x118/0x128 + el0t_64_sync+0x168/0x170 + +Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a +blocking grab of the super block rwsem if it isn't set. For normal issue +where IOCB_NOWAIT would always be set, this returns -EAGAIN which will +have io_uring core issue a blocking attempt of the write. That will in +turn also get completions run, ensuring forward progress. + +Since freezing requires CAP_SYS_ADMIN in the first place, this isn't +something that can be triggered by a regular user. + +Cc: stable@vger.kernel.org # 5.10+ +Reported-by: Peter Mann +Link: https://lore.kernel.org/io-uring/38c94aec-81c9-4f62-b44e-1d87f5597644@sh.cz +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + io_uring/rw.c | 23 +++++++++++++++++++++-- + 1 file changed, 21 insertions(+), 2 deletions(-) + +diff --git a/io_uring/rw.c b/io_uring/rw.c +index 0a0c1c9db0f90..e90404c812fa2 100644 +--- a/io_uring/rw.c ++++ b/io_uring/rw.c +@@ -860,6 +860,25 @@ int io_read(struct io_kiocb *req, unsigned int issue_flags) + return kiocb_done(req, ret, issue_flags); + } + ++static bool io_kiocb_start_write(struct io_kiocb *req, struct kiocb *kiocb) ++{ ++ struct inode *inode; ++ bool ret; ++ ++ if (!(req->flags & REQ_F_ISREG)) ++ return true; ++ if (!(kiocb->ki_flags & IOCB_NOWAIT)) { ++ kiocb_start_write(kiocb); ++ return true; ++ } ++ ++ inode = file_inode(kiocb->ki_filp); ++ ret = sb_start_write_trylock(inode->i_sb); ++ if (ret) ++ __sb_writers_release(inode->i_sb, SB_FREEZE_WRITE); ++ return ret; ++} ++ + int io_write(struct io_kiocb *req, unsigned int issue_flags) + { + struct io_rw *rw = io_kiocb_to_cmd(req, struct io_rw); +@@ -913,8 +932,8 @@ int io_write(struct io_kiocb *req, unsigned int issue_flags) + return ret; + } + +- if (req->flags & REQ_F_ISREG) +- kiocb_start_write(kiocb); ++ if (unlikely(!io_kiocb_start_write(req, kiocb))) ++ return -EAGAIN; + kiocb->ki_flags |= IOCB_WRITE; + + if (likely(req->file->f_op->write_iter)) +-- +2.43.0 + diff --git a/queue-6.6/iov_iter-fix-copy_page_from_iter_atomic-if-kmap_loca.patch b/queue-6.6/iov_iter-fix-copy_page_from_iter_atomic-if-kmap_loca.patch new file mode 100644 index 00000000000..7f2a0ced915 --- /dev/null +++ b/queue-6.6/iov_iter-fix-copy_page_from_iter_atomic-if-kmap_loca.patch @@ -0,0 +1,70 @@ +From 118a499c58e92a7769d03bcac71aa38944af2294 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 27 Oct 2024 15:23:23 -0700 +Subject: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP + +From: Hugh Dickins + +[ Upstream commit c749d9b7ebbc5716af7a95f7768634b30d9446ec ] + +generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, +on huge=always tmpfs, issues a warning and then hangs (interruptibly): + +WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 +CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 +... +copy_page_from_iter_atomic+0xa6/0x5ec +generic_perform_write+0xf6/0x1b4 +shmem_file_write_iter+0x54/0x67 + +Fix copy_page_from_iter_atomic() by limiting it in that case +(include/linux/skbuff.h skb_frag_must_loop() does similar). + +But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too +surprising, has outlived its usefulness, and should just be removed? + +Fixes: 908a1ad89466 ("iov_iter: Handle compound highmem pages in copy_page_from_iter_atomic()") +Signed-off-by: Hugh Dickins +Link: https://lore.kernel.org/r/dd5f0c89-186e-18e1-4f43-19a60f5a9774@google.com +Reviewed-by: Christoph Hellwig +Cc: stable@vger.kernel.org +Signed-off-by: Christian Brauner +Signed-off-by: Sasha Levin +--- + lib/iov_iter.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/lib/iov_iter.c b/lib/iov_iter.c +index 27234a820eeb3..a4bb47efafe37 100644 +--- a/lib/iov_iter.c ++++ b/lib/iov_iter.c +@@ -570,6 +570,8 @@ size_t copy_page_from_iter_atomic(struct page *page, size_t offset, + size_t bytes, struct iov_iter *i) + { + size_t n, copied = 0; ++ bool uses_kmap = IS_ENABLED(CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP) || ++ PageHighMem(page); + + if (!page_copy_sane(page, offset, bytes)) + return 0; +@@ -580,7 +582,7 @@ size_t copy_page_from_iter_atomic(struct page *page, size_t offset, + char *p; + + n = bytes - copied; +- if (PageHighMem(page)) { ++ if (uses_kmap) { + page += offset / PAGE_SIZE; + offset %= PAGE_SIZE; + n = min_t(size_t, n, PAGE_SIZE - offset); +@@ -594,7 +596,7 @@ size_t copy_page_from_iter_atomic(struct page *page, size_t offset, + kunmap_atomic(p); + copied += n; + offset += n; +- } while (PageHighMem(page) && copied != bytes && n > 0); ++ } while (uses_kmap && copied != bytes && n > 0); + + return copied; + } +-- +2.43.0 + diff --git a/queue-6.6/kasan-remove-vmalloc_percpu-test.patch b/queue-6.6/kasan-remove-vmalloc_percpu-test.patch new file mode 100644 index 00000000000..3a7c2e316dd --- /dev/null +++ b/queue-6.6/kasan-remove-vmalloc_percpu-test.patch @@ -0,0 +1,87 @@ +From f400638c4519a82344976d90b9d5ae9209923a5c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Oct 2024 18:07:06 +0200 +Subject: kasan: remove vmalloc_percpu test + +From: Andrey Konovalov + +[ Upstream commit 330d8df81f3673d6fb74550bbc9bb159d81b35f7 ] + +Commit 1a2473f0cbc0 ("kasan: improve vmalloc tests") added the +vmalloc_percpu KASAN test with the assumption that __alloc_percpu always +uses vmalloc internally, which is tagged by KASAN. + +However, __alloc_percpu might allocate memory from the first per-CPU +chunk, which is not allocated via vmalloc(). As a result, the test might +fail. + +Remove the test until proper KASAN annotation for the per-CPU allocated +are added; tracked in https://bugzilla.kernel.org/show_bug.cgi?id=215019. + +Link: https://lkml.kernel.org/r/20241022160706.38943-1-andrey.konovalov@linux.dev +Fixes: 1a2473f0cbc0 ("kasan: improve vmalloc tests") +Signed-off-by: Andrey Konovalov +Reported-by: Samuel Holland +Link: https://lore.kernel.org/all/4a245fff-cc46-44d1-a5f9-fd2f1c3764ae@sifive.com/ +Reported-by: Sabyrzhan Tasbolatov +Link: https://lore.kernel.org/all/CACzwLxiWzNqPBp4C1VkaXZ2wDwvY3yZeetCi1TLGFipKW77drA@mail.gmail.com/ +Cc: Alexander Potapenko +Cc: Andrey Ryabinin +Cc: Dmitry Vyukov +Cc: Marco Elver +Cc: Sabyrzhan Tasbolatov +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Sasha Levin +--- + mm/kasan/kasan_test.c | 27 --------------------------- + 1 file changed, 27 deletions(-) + +diff --git a/mm/kasan/kasan_test.c b/mm/kasan/kasan_test.c +index 0119075d2e58e..ecf9f5aa35200 100644 +--- a/mm/kasan/kasan_test.c ++++ b/mm/kasan/kasan_test.c +@@ -1381,32 +1381,6 @@ static void vm_map_ram_tags(struct kunit *test) + free_pages((unsigned long)p_ptr, 1); + } + +-static void vmalloc_percpu(struct kunit *test) +-{ +- char __percpu *ptr; +- int cpu; +- +- /* +- * This test is specifically crafted for the software tag-based mode, +- * the only tag-based mode that poisons percpu mappings. +- */ +- KASAN_TEST_NEEDS_CONFIG_ON(test, CONFIG_KASAN_SW_TAGS); +- +- ptr = __alloc_percpu(PAGE_SIZE, PAGE_SIZE); +- +- for_each_possible_cpu(cpu) { +- char *c_ptr = per_cpu_ptr(ptr, cpu); +- +- KUNIT_EXPECT_GE(test, (u8)get_tag(c_ptr), (u8)KASAN_TAG_MIN); +- KUNIT_EXPECT_LT(test, (u8)get_tag(c_ptr), (u8)KASAN_TAG_KERNEL); +- +- /* Make sure that in-bounds accesses don't crash the kernel. */ +- *c_ptr = 0; +- } +- +- free_percpu(ptr); +-} +- + /* + * Check that the assigned pointer tag falls within the [KASAN_TAG_MIN, + * KASAN_TAG_KERNEL) range (note: excluding the match-all tag) for tag-based +@@ -1562,7 +1536,6 @@ static struct kunit_case kasan_kunit_test_cases[] = { + KUNIT_CASE(vmalloc_oob), + KUNIT_CASE(vmap_tags), + KUNIT_CASE(vm_map_ram_tags), +- KUNIT_CASE(vmalloc_percpu), + KUNIT_CASE(match_all_not_assigned), + KUNIT_CASE(match_all_ptr_tag), + KUNIT_CASE(match_all_mem_tag), +-- +2.43.0 + diff --git a/queue-6.6/mctp-i2c-handle-null-header-address.patch b/queue-6.6/mctp-i2c-handle-null-header-address.patch new file mode 100644 index 00000000000..83878bd3da9 --- /dev/null +++ b/queue-6.6/mctp-i2c-handle-null-header-address.patch @@ -0,0 +1,44 @@ +From ab7dfb1d001cc24cccc2c81999765e8a4cbc7e6e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Oct 2024 18:25:14 +0800 +Subject: mctp i2c: handle NULL header address + +From: Matt Johnston + +[ Upstream commit 01e215975fd80af81b5b79f009d49ddd35976c13 ] + +daddr can be NULL if there is no neighbour table entry present, +in that case the tx packet should be dropped. + +saddr will usually be set by MCTP core, but check for NULL in case a +packet is transmitted by a different protocol. + +Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") +Cc: stable@vger.kernel.org +Reported-by: Dung Cao +Signed-off-by: Matt Johnston +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20241022-mctp-i2c-null-dest-v3-1-e929709956c5@codeconstruct.com.au +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/mctp/mctp-i2c.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/net/mctp/mctp-i2c.c b/drivers/net/mctp/mctp-i2c.c +index b37a9e4bade4a..20b8d7d528baf 100644 +--- a/drivers/net/mctp/mctp-i2c.c ++++ b/drivers/net/mctp/mctp-i2c.c +@@ -547,6 +547,9 @@ static int mctp_i2c_header_create(struct sk_buff *skb, struct net_device *dev, + if (len > MCTP_I2C_MAXMTU) + return -EMSGSIZE; + ++ if (!daddr || !saddr) ++ return -EINVAL; ++ + lldst = *((u8 *)daddr); + llsrc = *((u8 *)saddr); + +-- +2.43.0 + diff --git a/queue-6.6/mei-use-kvmalloc-for-read-buffer.patch b/queue-6.6/mei-use-kvmalloc-for-read-buffer.patch new file mode 100644 index 00000000000..506a208e450 --- /dev/null +++ b/queue-6.6/mei-use-kvmalloc-for-read-buffer.patch @@ -0,0 +1,55 @@ +From 3d7c04db1c337d97d63e13b125a315435feb0bce Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 15 Oct 2024 15:31:57 +0300 +Subject: mei: use kvmalloc for read buffer + +From: Alexander Usyskin + +[ Upstream commit 4adf613e01bf99e1739f6ff3e162ad5b7d578d1a ] + +Read buffer is allocated according to max message size, reported by +the firmware and may reach 64K in systems with pxp client. +Contiguous 64k allocation may fail under memory pressure. +Read buffer is used as in-driver message storage and not required +to be contiguous. +Use kvmalloc to allow kernel to allocate non-contiguous memory. + +Fixes: 3030dc056459 ("mei: add wrapper for queuing control commands.") +Cc: stable +Reported-by: Rohit Agarwal +Closes: https://lore.kernel.org/all/20240813084542.2921300-1-rohiagar@chromium.org/ +Tested-by: Brian Geffon +Signed-off-by: Alexander Usyskin +Acked-by: Tomas Winkler +Link: https://lore.kernel.org/r/20241015123157.2337026-1-alexander.usyskin@intel.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Sasha Levin +--- + drivers/misc/mei/client.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c +index 32f2287823184..699fa2362ed4d 100644 +--- a/drivers/misc/mei/client.c ++++ b/drivers/misc/mei/client.c +@@ -321,7 +321,7 @@ void mei_io_cb_free(struct mei_cl_cb *cb) + return; + + list_del(&cb->list); +- kfree(cb->buf.data); ++ kvfree(cb->buf.data); + kfree(cb->ext_hdr); + kfree(cb); + } +@@ -497,7 +497,7 @@ struct mei_cl_cb *mei_cl_alloc_cb(struct mei_cl *cl, size_t length, + if (length == 0) + return cb; + +- cb->buf.data = kmalloc(roundup(length, MEI_SLOT_SIZE), GFP_KERNEL); ++ cb->buf.data = kvmalloc(roundup(length, MEI_SLOT_SIZE), GFP_KERNEL); + if (!cb->buf.data) { + mei_io_cb_free(cb); + return NULL; +-- +2.43.0 + diff --git a/queue-6.6/mm-page_alloc-let-gfp_atomic-order-0-allocs-access-h.patch b/queue-6.6/mm-page_alloc-let-gfp_atomic-order-0-allocs-access-h.patch new file mode 100644 index 00000000000..b6182ba916b --- /dev/null +++ b/queue-6.6/mm-page_alloc-let-gfp_atomic-order-0-allocs-access-h.patch @@ -0,0 +1,88 @@ +From 2ccee79e5c59a0d1590b1fb75b9e38736100595a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 11 Oct 2024 13:07:37 +0100 +Subject: mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic + reserves + +From: Matt Fleming + +[ Upstream commit 281dd25c1a018261a04d1b8bf41a0674000bfe38 ] + +Under memory pressure it's possible for GFP_ATOMIC order-0 allocations to +fail even though free pages are available in the highatomic reserves. +GFP_ATOMIC allocations cannot trigger unreserve_highatomic_pageblock() +since it's only run from reclaim. + +Given that such allocations will pass the watermarks in +__zone_watermark_unusable_free(), it makes sense to fallback to highatomic +reserves the same way that ALLOC_OOM can. + +This fixes order-0 page allocation failures observed on Cloudflare's fleet +when handling network packets: + + kswapd1: page allocation failure: order:0, mode:0x820(GFP_ATOMIC), + nodemask=(null),cpuset=/,mems_allowed=0-7 + CPU: 10 PID: 696 Comm: kswapd1 Kdump: loaded Tainted: G O 6.6.43-CUSTOM #1 + Hardware name: MACHINE + Call Trace: + + dump_stack_lvl+0x3c/0x50 + warn_alloc+0x13a/0x1c0 + __alloc_pages_slowpath.constprop.0+0xc9d/0xd10 + __alloc_pages+0x327/0x340 + __napi_alloc_skb+0x16d/0x1f0 + bnxt_rx_page_skb+0x96/0x1b0 [bnxt_en] + bnxt_rx_pkt+0x201/0x15e0 [bnxt_en] + __bnxt_poll_work+0x156/0x2b0 [bnxt_en] + bnxt_poll+0xd9/0x1c0 [bnxt_en] + __napi_poll+0x2b/0x1b0 + bpf_trampoline_6442524138+0x7d/0x1000 + __napi_poll+0x5/0x1b0 + net_rx_action+0x342/0x740 + handle_softirqs+0xcf/0x2b0 + irq_exit_rcu+0x6c/0x90 + sysvec_apic_timer_interrupt+0x72/0x90 + + +[mfleming@cloudflare.com: update comment] + Link: https://lkml.kernel.org/r/20241015125158.3597702-1-matt@readmodwrite.com +Link: https://lkml.kernel.org/r/20241011120737.3300370-1-matt@readmodwrite.com +Link: https://lore.kernel.org/all/CAGis_TWzSu=P7QJmjD58WWiu3zjMTVKSzdOwWE8ORaGytzWJwQ@mail.gmail.com/ +Fixes: 1d91df85f399 ("mm/page_alloc: handle a missing case for memalloc_nocma_{save/restore} APIs") +Signed-off-by: Matt Fleming +Suggested-by: Vlastimil Babka +Reviewed-by: Vlastimil Babka +Cc: Mel Gorman +Cc: Michal Hocko +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Sasha Levin +--- + mm/page_alloc.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +diff --git a/mm/page_alloc.c b/mm/page_alloc.c +index edb32635037f4..1bbbf2f8b7e4c 100644 +--- a/mm/page_alloc.c ++++ b/mm/page_alloc.c +@@ -2658,12 +2658,12 @@ struct page *rmqueue_buddy(struct zone *preferred_zone, struct zone *zone, + page = __rmqueue(zone, order, migratetype, alloc_flags); + + /* +- * If the allocation fails, allow OOM handling access +- * to HIGHATOMIC reserves as failing now is worse than +- * failing a high-order atomic allocation in the +- * future. ++ * If the allocation fails, allow OOM handling and ++ * order-0 (atomic) allocs access to HIGHATOMIC ++ * reserves as failing now is worse than failing a ++ * high-order atomic allocation in the future. + */ +- if (!page && (alloc_flags & ALLOC_OOM)) ++ if (!page && (alloc_flags & (ALLOC_OOM|ALLOC_NON_BLOCK))) + page = __rmqueue_smallest(zone, order, MIGRATE_HIGHATOMIC); + + if (!page) { +-- +2.43.0 + diff --git a/queue-6.6/mptcp-init-protect-sched-with-rcu_read_lock.patch b/queue-6.6/mptcp-init-protect-sched-with-rcu_read_lock.patch new file mode 100644 index 00000000000..391d0f73bd5 --- /dev/null +++ b/queue-6.6/mptcp-init-protect-sched-with-rcu_read_lock.patch @@ -0,0 +1,79 @@ +From 25e187b892b76ef7126b55f42c61eb84fdd33ddd Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 21 Oct 2024 12:25:26 +0200 +Subject: mptcp: init: protect sched with rcu_read_lock + +From: Matthieu Baerts (NGI0) + +[ Upstream commit 3deb12c788c385e17142ce6ec50f769852fcec65 ] + +Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT +creates this splat when an MPTCP socket is created: + + ============================= + WARNING: suspicious RCU usage + 6.12.0-rc2+ #11 Not tainted + ----------------------------- + net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! + + other info that might help us debug this: + + rcu_scheduler_active = 2, debug_locks = 1 + no locks held by mptcp_connect/176. + + stack backtrace: + CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 + Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 + Call Trace: + + dump_stack_lvl (lib/dump_stack.c:123) + lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) + mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) + mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) + ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) + inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) + ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) + __sock_create (net/socket.c:1576) + __sys_socket (net/socket.c:1671) + ? __pfx___sys_socket (net/socket.c:1712) + ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) + __x64_sys_socket (net/socket.c:1728) + do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) + entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) + +That's because when the socket is initialised, rcu_read_lock() is not +used despite the explicit comment written above the declaration of +mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the +warning. + +Fixes: 1730b2b2c5a5 ("mptcp: add sched in mptcp_sock") +Cc: stable@vger.kernel.org +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/523 +Reviewed-by: Geliang Tang +Signed-off-by: Matthieu Baerts (NGI0) +Reviewed-by: Simon Horman +Link: https://patch.msgid.link/20241021-net-mptcp-sched-lock-v1-1-637759cf061c@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/mptcp/protocol.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c +index 8cdd4ec152e7b..cd6f8d655c185 100644 +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -2823,8 +2823,10 @@ static int mptcp_init_sock(struct sock *sk) + if (unlikely(!net->mib.mptcp_statistics) && !mptcp_mib_alloc(net)) + return -ENOMEM; + ++ rcu_read_lock(); + ret = mptcp_init_sched(mptcp_sk(sk), + mptcp_sched_find(mptcp_get_scheduler(net))); ++ rcu_read_unlock(); + if (ret) + return ret; + +-- +2.43.0 + diff --git a/queue-6.6/nvmet-auth-assign-dh_key-to-null-after-kfree_sensiti.patch b/queue-6.6/nvmet-auth-assign-dh_key-to-null-after-kfree_sensiti.patch new file mode 100644 index 00000000000..1b8e1854b65 --- /dev/null +++ b/queue-6.6/nvmet-auth-assign-dh_key-to-null-after-kfree_sensiti.patch @@ -0,0 +1,41 @@ +From 3e5cb1d7e18b7d305ef4b8ab96726c201e57256b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 16 Sep 2024 22:41:37 +0500 +Subject: nvmet-auth: assign dh_key to NULL after kfree_sensitive + +From: Vitaliy Shevtsov + +[ Upstream commit d2f551b1f72b4c508ab9298419f6feadc3b5d791 ] + +ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() +for the same controller. So it's better to nullify it after release on +error path in order to avoid double free later in nvmet_destroy_auth(). + +Found by Linux Verification Center (linuxtesting.org) with Svace. + +Fixes: 7a277c37d352 ("nvmet-auth: Diffie-Hellman key exchange support") +Cc: stable@vger.kernel.org +Signed-off-by: Vitaliy Shevtsov +Reviewed-by: Christoph Hellwig +Reviewed-by: Hannes Reinecke +Signed-off-by: Keith Busch +Signed-off-by: Sasha Levin +--- + drivers/nvme/target/auth.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/nvme/target/auth.c b/drivers/nvme/target/auth.c +index aacc05ec00c2b..74791078fdebc 100644 +--- a/drivers/nvme/target/auth.c ++++ b/drivers/nvme/target/auth.c +@@ -101,6 +101,7 @@ int nvmet_setup_dhgroup(struct nvmet_ctrl *ctrl, u8 dhgroup_id) + pr_debug("%s: ctrl %d failed to generate private key, err %d\n", + __func__, ctrl->cntlid, ret); + kfree_sensitive(ctrl->dh_key); ++ ctrl->dh_key = NULL; + return ret; + } + ctrl->dh_keysize = crypto_kpp_maxsize(ctrl->dh_tfm); +-- +2.43.0 + diff --git a/queue-6.6/ocfs2-pass-u64-to-ocfs2_truncate_inline-maybe-overfl.patch b/queue-6.6/ocfs2-pass-u64-to-ocfs2_truncate_inline-maybe-overfl.patch new file mode 100644 index 00000000000..c296b8f8b49 --- /dev/null +++ b/queue-6.6/ocfs2-pass-u64-to-ocfs2_truncate_inline-maybe-overfl.patch @@ -0,0 +1,60 @@ +From 5f904dfbb85ea1f8ccbb7be0d11b7552ae0c1621 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 16 Oct 2024 19:43:47 +0800 +Subject: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow + +From: Edward Adam Davis + +[ Upstream commit bc0a2f3a73fcdac651fca64df39306d1e5ebe3b0 ] + +Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two +reasons for this: first, the parameter value passed is greater than +ocfs2_max_inline_data_with_xattr, second, the start and end parameters of +ocfs2_truncate_inline are "unsigned int". + +So, we need to add a sanity check for byte_start and byte_len right before +ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater +than ocfs2_max_inline_data_with_xattr return -EINVAL. + +Link: https://lkml.kernel.org/r/tencent_D48DB5122ADDAEDDD11918CFB68D93258C07@qq.com +Fixes: 1afc32b95233 ("ocfs2: Write support for inline data") +Signed-off-by: Edward Adam Davis +Reported-by: syzbot+81092778aac03460d6b7@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=81092778aac03460d6b7 +Reviewed-by: Joseph Qi +Cc: Joel Becker +Cc: Joseph Qi +Cc: Mark Fasheh +Cc: Junxiao Bi +Cc: Changwei Ge +Cc: Gang He +Cc: Jun Piao +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Sasha Levin +--- + fs/ocfs2/file.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c +index 8bbe4a2b48a2a..aa39d5d2d94f1 100644 +--- a/fs/ocfs2/file.c ++++ b/fs/ocfs2/file.c +@@ -1783,6 +1783,14 @@ int ocfs2_remove_inode_range(struct inode *inode, + return 0; + + if (OCFS2_I(inode)->ip_dyn_features & OCFS2_INLINE_DATA_FL) { ++ int id_count = ocfs2_max_inline_data_with_xattr(inode->i_sb, di); ++ ++ if (byte_start > id_count || byte_start + byte_len > id_count) { ++ ret = -EINVAL; ++ mlog_errno(ret); ++ goto out; ++ } ++ + ret = ocfs2_truncate_inline(inode, di_bh, byte_start, + byte_start + byte_len, 0); + if (ret) { +-- +2.43.0 + diff --git a/queue-6.6/phy-freescale-imx8m-pcie-do-cmn_rst-just-before-phy-.patch b/queue-6.6/phy-freescale-imx8m-pcie-do-cmn_rst-just-before-phy-.patch new file mode 100644 index 00000000000..949ff92d9f2 --- /dev/null +++ b/queue-6.6/phy-freescale-imx8m-pcie-do-cmn_rst-just-before-phy-.patch @@ -0,0 +1,97 @@ +From e86229a03a3f87760ae4f71fb3231db0082259af Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 21 Oct 2024 11:52:41 -0400 +Subject: phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check + +From: Richard Zhu + +[ Upstream commit f89263b69731e0144d275fff777ee0dd92069200 ] + +When enable initcall_debug together with higher debug level below. +CONFIG_CONSOLE_LOGLEVEL_DEFAULT=9 +CONFIG_CONSOLE_LOGLEVEL_QUIET=9 +CONFIG_MESSAGE_LOGLEVEL_DEFAULT=7 + +The initialization of i.MX8MP PCIe PHY might be timeout failed randomly. +To fix this issue, adjust the sequence of the resets refer to the power +up sequence listed below. + +i.MX8MP PCIe PHY power up sequence: + /--------------------------------------------- +1.8v supply ---------/ + /--------------------------------------------------- +0.8v supply ---/ + + ---\ /-------------------------------------------------- + X REFCLK Valid +Reference Clock ---/ \-------------------------------------------------- + ------------------------------------------- + | +i_init_restn -------------- + ------------------------------------ + | +i_cmn_rstn --------------------- + ------------------------------- + | +o_pll_lock_done -------------------------- + +Logs: +imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges: +imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000 +imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000 +probe of clk_imx8mp_audiomix.reset.0 returned 0 after 1052 usecs +probe of 30e20000.clock-controller returned 0 after 32971 usecs +phy phy-32f00000.pcie-phy.4: phy poweron failed --> -110 +probe of 30e10000.dma-controller returned 0 after 10235 usecs +imx6q-pcie 33800000.pcie: waiting for PHY ready timeout! +dwhdmi-imx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (samsung_dw_hdmi_phy2) +imx6q-pcie 33800000.pcie: probe with driver imx6q-pcie failed with error -110 + +Fixes: dce9edff16ee ("phy: freescale: imx8m-pcie: Add i.MX8MP PCIe PHY support") +Cc: stable@vger.kernel.org +Signed-off-by: Richard Zhu +Signed-off-by: Frank Li + +v2 changes: +- Rebase to latest fixes branch of linux-phy git repo. +- Richard's environment have problem and can't sent out patch. So I help +post this fix patch. + +Link: https://lore.kernel.org/r/20241021155241.943665-1-Frank.Li@nxp.com +Signed-off-by: Vinod Koul +Signed-off-by: Sasha Levin +--- + drivers/phy/freescale/phy-fsl-imx8m-pcie.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +diff --git a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c +index 11fcb1867118c..e98361dcdeadf 100644 +--- a/drivers/phy/freescale/phy-fsl-imx8m-pcie.c ++++ b/drivers/phy/freescale/phy-fsl-imx8m-pcie.c +@@ -141,11 +141,6 @@ static int imx8_pcie_phy_power_on(struct phy *phy) + IMX8MM_GPR_PCIE_REF_CLK_PLL); + usleep_range(100, 200); + +- /* Do the PHY common block reset */ +- regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, +- IMX8MM_GPR_PCIE_CMN_RST, +- IMX8MM_GPR_PCIE_CMN_RST); +- + switch (imx8_phy->drvdata->variant) { + case IMX8MP: + reset_control_deassert(imx8_phy->perst); +@@ -156,6 +151,11 @@ static int imx8_pcie_phy_power_on(struct phy *phy) + break; + } + ++ /* Do the PHY common block reset */ ++ regmap_update_bits(imx8_phy->iomuxc_gpr, IOMUXC_GPR14, ++ IMX8MM_GPR_PCIE_CMN_RST, ++ IMX8MM_GPR_PCIE_CMN_RST); ++ + /* Polling to check the phy is ready or not. */ + ret = readl_poll_timeout(imx8_phy->base + IMX8MM_PCIE_PHY_CMN_REG075, + val, val == ANA_PLL_DONE, 10, 20000); +-- +2.43.0 + diff --git a/queue-6.6/riscv-efi-set-nx-compat-flag-in-pe-coff-header.patch b/queue-6.6/riscv-efi-set-nx-compat-flag-in-pe-coff-header.patch new file mode 100644 index 00000000000..5058e76b58a --- /dev/null +++ b/queue-6.6/riscv-efi-set-nx-compat-flag-in-pe-coff-header.patch @@ -0,0 +1,48 @@ +From d93f61c880ee256aa593b373c99a088a56784daa Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 29 Sep 2024 16:02:33 +0200 +Subject: riscv: efi: Set NX compat flag in PE/COFF header + +From: Heinrich Schuchardt + +[ Upstream commit d41373a4b910961df5a5e3527d7bde6ad45ca438 ] + +The IMAGE_DLLCHARACTERISTICS_NX_COMPAT informs the firmware that the +EFI binary does not rely on pages that are both executable and +writable. + +The flag is used by some distro versions of GRUB to decide if the EFI +binary may be executed. + +As the Linux kernel neither has RWX sections nor needs RWX pages for +relocation we should set the flag. + +Cc: Ard Biesheuvel +Cc: +Signed-off-by: Heinrich Schuchardt +Reviewed-by: Emil Renner Berthing +Fixes: cb7d2dd5612a ("RISC-V: Add PE/COFF header for EFI stub") +Acked-by: Ard Biesheuvel +Link: https://lore.kernel.org/r/20240929140233.211800-1-heinrich.schuchardt@canonical.com +Signed-off-by: Palmer Dabbelt +Signed-off-by: Sasha Levin +--- + arch/riscv/kernel/efi-header.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/riscv/kernel/efi-header.S b/arch/riscv/kernel/efi-header.S +index 515b2dfbca75b..c5f17c2710b58 100644 +--- a/arch/riscv/kernel/efi-header.S ++++ b/arch/riscv/kernel/efi-header.S +@@ -64,7 +64,7 @@ extra_header_fields: + .long efi_header_end - _start // SizeOfHeaders + .long 0 // CheckSum + .short IMAGE_SUBSYSTEM_EFI_APPLICATION // Subsystem +- .short 0 // DllCharacteristics ++ .short IMAGE_DLL_CHARACTERISTICS_NX_COMPAT // DllCharacteristics + .quad 0 // SizeOfStackReserve + .quad 0 // SizeOfStackCommit + .quad 0 // SizeOfHeapReserve +-- +2.43.0 + diff --git a/queue-6.6/riscv-remove-duplicated-get_rm.patch b/queue-6.6/riscv-remove-duplicated-get_rm.patch new file mode 100644 index 00000000000..793928d0110 --- /dev/null +++ b/queue-6.6/riscv-remove-duplicated-get_rm.patch @@ -0,0 +1,38 @@ +From 30e9ed2087795583a9cec6eb79b03335f294f831 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 17:41:39 +0800 +Subject: riscv: Remove duplicated GET_RM + +From: Chunyan Zhang + +[ Upstream commit 164f66de6bb6ef454893f193c898dc8f1da6d18b ] + +The macro GET_RM defined twice in this file, one can be removed. + +Reviewed-by: Alexandre Ghiti +Signed-off-by: Chunyan Zhang +Fixes: 956d705dd279 ("riscv: Unaligned load/store handling for M_MODE") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20241008094141.549248-3-zhangchunyan@iscas.ac.cn +Signed-off-by: Palmer Dabbelt +Signed-off-by: Sasha Levin +--- + arch/riscv/kernel/traps_misaligned.c | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/arch/riscv/kernel/traps_misaligned.c b/arch/riscv/kernel/traps_misaligned.c +index e867fe465164e..edae2735ebe34 100644 +--- a/arch/riscv/kernel/traps_misaligned.c ++++ b/arch/riscv/kernel/traps_misaligned.c +@@ -132,8 +132,6 @@ + #define REG_PTR(insn, pos, regs) \ + (ulong *)((ulong)(regs) + REG_OFFSET(insn, pos)) + +-#define GET_RM(insn) (((insn) >> 12) & 7) +- + #define GET_RS1(insn, regs) (*REG_PTR(insn, SH_RS1, regs)) + #define GET_RS2(insn, regs) (*REG_PTR(insn, SH_RS2, regs)) + #define GET_RS1S(insn, regs) (*REG_PTR(RVC_RS1S(insn), 0, regs)) +-- +2.43.0 + diff --git a/queue-6.6/riscv-remove-unused-generating_asm_offsets.patch b/queue-6.6/riscv-remove-unused-generating_asm_offsets.patch new file mode 100644 index 00000000000..747917a8af6 --- /dev/null +++ b/queue-6.6/riscv-remove-unused-generating_asm_offsets.patch @@ -0,0 +1,44 @@ +From 64bb1c5e98d0929388248bdb30530628415792f5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 17:41:38 +0800 +Subject: riscv: Remove unused GENERATING_ASM_OFFSETS + +From: Chunyan Zhang + +[ Upstream commit 46d4e5ac6f2f801f97bcd0ec82365969197dc9b1 ] + +The macro is not used in the current version of kernel, it looks like +can be removed to avoid a build warning: + +../arch/riscv/kernel/asm-offsets.c: At top level: +../arch/riscv/kernel/asm-offsets.c:7: warning: macro "GENERATING_ASM_OFFSETS" is not used [-Wunused-macros] + 7 | #define GENERATING_ASM_OFFSETS + +Fixes: 9639a44394b9 ("RISC-V: Provide a cleaner raw_smp_processor_id()") +Cc: stable@vger.kernel.org +Reviewed-by: Alexandre Ghiti +Tested-by: Alexandre Ghiti +Signed-off-by: Chunyan Zhang +Link: https://lore.kernel.org/r/20241008094141.549248-2-zhangchunyan@iscas.ac.cn +Signed-off-by: Palmer Dabbelt +Signed-off-by: Sasha Levin +--- + arch/riscv/kernel/asm-offsets.c | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/arch/riscv/kernel/asm-offsets.c b/arch/riscv/kernel/asm-offsets.c +index 9f535d5de33f9..6a992cba2f287 100644 +--- a/arch/riscv/kernel/asm-offsets.c ++++ b/arch/riscv/kernel/asm-offsets.c +@@ -4,8 +4,6 @@ + * Copyright (C) 2017 SiFive + */ + +-#define GENERATING_ASM_OFFSETS +- + #include + #include + #include +-- +2.43.0 + diff --git a/queue-6.6/riscv-use-u-to-format-the-output-of-cpu.patch b/queue-6.6/riscv-use-u-to-format-the-output-of-cpu.patch new file mode 100644 index 00000000000..c34934a88b9 --- /dev/null +++ b/queue-6.6/riscv-use-u-to-format-the-output-of-cpu.patch @@ -0,0 +1,43 @@ +From 5f68d9a5d7a1597fc4b549fa2be247873e92fed4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 17 Oct 2024 11:20:10 +0800 +Subject: riscv: Use '%u' to format the output of 'cpu' + +From: WangYuli + +[ Upstream commit e0872ab72630dada3ae055bfa410bf463ff1d1e0 ] + +'cpu' is an unsigned integer, so its conversion specifier should +be %u, not %d. + +Suggested-by: Wentao Guan +Suggested-by: Maciej W. Rozycki +Link: https://lore.kernel.org/all/alpine.DEB.2.21.2409122309090.40372@angie.orcam.me.uk/ +Signed-off-by: WangYuli +Reviewed-by: Charlie Jenkins +Tested-by: Charlie Jenkins +Fixes: f1e58583b9c7 ("RISC-V: Support cpu hotplug") +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/4C127DEECDA287C8+20241017032010.96772-1-wangyuli@uniontech.com +Signed-off-by: Palmer Dabbelt +Signed-off-by: Sasha Levin +--- + arch/riscv/kernel/cpu-hotplug.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/riscv/kernel/cpu-hotplug.c b/arch/riscv/kernel/cpu-hotplug.c +index 457a18efcb114..6b710ef9d9aef 100644 +--- a/arch/riscv/kernel/cpu-hotplug.c ++++ b/arch/riscv/kernel/cpu-hotplug.c +@@ -65,7 +65,7 @@ void arch_cpuhp_cleanup_dead_cpu(unsigned int cpu) + if (cpu_ops[cpu]->cpu_is_stopped) + ret = cpu_ops[cpu]->cpu_is_stopped(cpu); + if (ret) +- pr_warn("CPU%d may not have stopped: %d\n", cpu, ret); ++ pr_warn("CPU%u may not have stopped: %d\n", cpu, ret); + } + + /* +-- +2.43.0 + diff --git a/queue-6.6/riscv-vdso-prevent-the-compiler-from-inserting-calls.patch b/queue-6.6/riscv-vdso-prevent-the-compiler-from-inserting-calls.patch new file mode 100644 index 00000000000..d78dd3377b9 --- /dev/null +++ b/queue-6.6/riscv-vdso-prevent-the-compiler-from-inserting-calls.patch @@ -0,0 +1,40 @@ +From 875cda094dcc230dd0976a0009156a8e022d7fb3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 16 Oct 2024 10:36:24 +0200 +Subject: riscv: vdso: Prevent the compiler from inserting calls to memset() + +From: Alexandre Ghiti + +[ Upstream commit bf40167d54d55d4b54d0103713d86a8638fb9290 ] + +The compiler is smart enough to insert a call to memset() in +riscv_vdso_get_cpus(), which generates a dynamic relocation. + +So prevent this by using -fno-builtin option. + +Fixes: e2c0cdfba7f6 ("RISC-V: User-facing API") +Cc: stable@vger.kernel.org +Signed-off-by: Alexandre Ghiti +Reviewed-by: Guo Ren +Link: https://lore.kernel.org/r/20241016083625.136311-2-alexghiti@rivosinc.com +Signed-off-by: Palmer Dabbelt +Signed-off-by: Sasha Levin +--- + arch/riscv/kernel/vdso/Makefile | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile +index e8aa7c3800075..d58f32a2035b1 100644 +--- a/arch/riscv/kernel/vdso/Makefile ++++ b/arch/riscv/kernel/vdso/Makefile +@@ -18,6 +18,7 @@ obj-vdso = $(patsubst %, %.o, $(vdso-syms)) note.o + + ccflags-y := -fno-stack-protector + ccflags-y += -DDISABLE_BRANCH_PROFILING ++ccflags-y += -fno-builtin + + ifneq ($(c-gettimeofday-y),) + CFLAGS_vgettimeofday.o += -fPIC -include $(c-gettimeofday-y) +-- +2.43.0 + diff --git a/queue-6.6/sched-numa-fix-the-potential-null-pointer-dereferenc.patch b/queue-6.6/sched-numa-fix-the-potential-null-pointer-dereferenc.patch new file mode 100644 index 00000000000..c18ccb8b12d --- /dev/null +++ b/queue-6.6/sched-numa-fix-the-potential-null-pointer-dereferenc.patch @@ -0,0 +1,90 @@ +From 550226e2222777e4194372a23a0f9bff1d7a8c18 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 25 Oct 2024 10:22:08 +0800 +Subject: sched/numa: Fix the potential null pointer dereference in + task_numa_work() + +From: Shawn Wang + +[ Upstream commit 9c70b2a33cd2aa6a5a59c5523ef053bd42265209 ] + +When running stress-ng-vm-segv test, we found a null pointer dereference +error in task_numa_work(). Here is the backtrace: + + [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 + ...... + [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se + ...... + [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) + [323676.067115] pc : vma_migratable+0x1c/0xd0 + [323676.067122] lr : task_numa_work+0x1ec/0x4e0 + [323676.067127] sp : ffff8000ada73d20 + [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 + [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 + [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 + [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 + [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 + [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 + [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 + [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 + [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 + [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 + [323676.067152] Call trace: + [323676.067153] vma_migratable+0x1c/0xd0 + [323676.067155] task_numa_work+0x1ec/0x4e0 + [323676.067157] task_work_run+0x78/0xd8 + [323676.067161] do_notify_resume+0x1ec/0x290 + [323676.067163] el0_svc+0x150/0x160 + [323676.067167] el0t_64_sync_handler+0xf8/0x128 + [323676.067170] el0t_64_sync+0x17c/0x180 + [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) + [323676.067177] SMP: stopping secondary CPUs + [323676.070184] Starting crashdump kernel... + +stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error +handling function of the system, which tries to cause a SIGSEGV error on +return from unmapping the whole address space of the child process. + +Normally this program will not cause kernel crashes. But before the +munmap system call returns to user mode, a potential task_numa_work() +for numa balancing could be added and executed. In this scenario, since the +child process has no vma after munmap, the vma_next() in task_numa_work() +will return a null pointer even if the vma iterator restarts from 0. + +Recheck the vma pointer before dereferencing it in task_numa_work(). + +Fixes: 214dbc428137 ("sched: convert to vma iterator") +Signed-off-by: Shawn Wang +Signed-off-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org # v6.2+ +Link: https://lkml.kernel.org/r/20241025022208.125527-1-shawnwang@linux.alibaba.com +Signed-off-by: Sasha Levin +--- + kernel/sched/fair.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c +index 5eb4807bad209..db59bf549c644 100644 +--- a/kernel/sched/fair.c ++++ b/kernel/sched/fair.c +@@ -3314,7 +3314,7 @@ static void task_numa_work(struct callback_head *work) + vma = vma_next(&vmi); + } + +- do { ++ for (; vma; vma = vma_next(&vmi)) { + if (!vma_migratable(vma) || !vma_policy_mof(vma) || + is_vm_hugetlb_page(vma) || (vma->vm_flags & VM_MIXEDMAP)) { + trace_sched_skip_vma_numa(mm, vma, NUMAB_SKIP_UNSUITABLE); +@@ -3434,7 +3434,7 @@ static void task_numa_work(struct callback_head *work) + */ + if (vma_pids_forced) + break; +- } for_each_vma(vmi, vma); ++ } + + /* + * If no VMAs are remaining and VMAs were skipped due to the PID +-- +2.43.0 + diff --git a/queue-6.6/series b/queue-6.6/series index 636bc008ae7..bd27ca27e96 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -106,3 +106,32 @@ thunderbolt-honor-tmu-requirements-in-the-domain-when-setting-tmu-mode.patch cxl-port-fix-use-after-free-permit-out-of-order-decoder-shutdown.patch mmc-sdhci-pci-gli-gl9767-fix-low-power-mode-on-the-set-clock-function.patch mmc-sdhci-pci-gli-gl9767-fix-low-power-mode-in-the-sd-express-process.patch +block-fix-sanity-checks-in-blk_rq_map_user_bvec.patch +cgroup-bpf-use-a-dedicated-workqueue-for-cgroup-bpf-.patch +phy-freescale-imx8m-pcie-do-cmn_rst-just-before-phy-.patch +spi-spi-fsl-dspi-fix-crash-when-not-using-gpio-chip-.patch +riscv-vdso-prevent-the-compiler-from-inserting-calls.patch +input-edt-ft5x06-fix-regmap-leak-when-probe-fails.patch +alsa-hda-realtek-limit-internal-mic-boost-on-dell-pl.patch +riscv-efi-set-nx-compat-flag-in-pe-coff-header.patch +riscv-use-u-to-format-the-output-of-cpu.patch +riscv-remove-unused-generating_asm_offsets.patch +riscv-remove-duplicated-get_rm.patch +cxl-port-fix-cxl_bus_rescan-vs-bus_rescan_devices.patch +cxl-acpi-ensure-ports-ready-at-cxl_acpi_probe-return.patch +sched-numa-fix-the-potential-null-pointer-dereferenc.patch +iov_iter-fix-copy_page_from_iter_atomic-if-kmap_loca.patch +mptcp-init-protect-sched-with-rcu_read_lock.patch +mei-use-kvmalloc-for-read-buffer.patch +mm-page_alloc-let-gfp_atomic-order-0-allocs-access-h.patch +x86-traps-enable-ubsan-traps-on-x86.patch +x86-traps-move-kmsan-check-after-instrumentation_beg.patch +ocfs2-pass-u64-to-ocfs2_truncate_inline-maybe-overfl.patch +mctp-i2c-handle-null-header-address.patch +xfs-fix-finding-a-last-resort-ag-in-xfs_filestream_p.patch +alsa-hda-realtek-fix-headset-mic-on-tuxedo-gemini-17.patch +alsa-hda-realtek-fix-headset-mic-on-tuxedo-stellaris.patch +nvmet-auth-assign-dh_key-to-null-after-kfree_sensiti.patch +kasan-remove-vmalloc_percpu-test.patch +io_uring-rw-fix-missing-nowait-check-for-o_direct-st.patch +vmscan-migrate-fix-page-count-imbalance-on-node-stat.patch diff --git a/queue-6.6/spi-spi-fsl-dspi-fix-crash-when-not-using-gpio-chip-.patch b/queue-6.6/spi-spi-fsl-dspi-fix-crash-when-not-using-gpio-chip-.patch new file mode 100644 index 00000000000..e981880ba9f --- /dev/null +++ b/queue-6.6/spi-spi-fsl-dspi-fix-crash-when-not-using-gpio-chip-.patch @@ -0,0 +1,86 @@ +From 98e1699e56065b6131579a18bee024b3ccc90101 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 23 Oct 2024 16:30:32 -0400 +Subject: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select + +From: Frank Li + +[ Upstream commit 25f00a13dccf8e45441265768de46c8bf58e08f6 ] + +Add check for the return value of spi_get_csgpiod() to avoid passing a NULL +pointer to gpiod_direction_output(), preventing a crash when GPIO chip +select is not used. + +Fix below crash: +[ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 +[ 4.260762] Mem abort info: +[ 4.263556] ESR = 0x0000000096000004 +[ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits +[ 4.272624] SET = 0, FnV = 0 +[ 4.275681] EA = 0, S1PTW = 0 +[ 4.278822] FSC = 0x04: level 0 translation fault +[ 4.283704] Data abort info: +[ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 +[ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 +[ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 +[ 4.302445] [0000000000000000] user address but active_mm is swapper +[ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP +[ 4.315072] Modules linked in: +[ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 +[ 4.328130] Hardware name: LS1046A QDS Board (DT) +[ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) +[ 4.339794] pc : gpiod_direction_output+0x34/0x5c +[ 4.344505] lr : gpiod_direction_output+0x18/0x5c +[ 4.349208] sp : ffff80008003b8f0 +[ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 +[ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 +[ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 +[ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff +[ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 +[ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e +[ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 +[ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 +[ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 +[ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 +[ 4.423921] Call trace: +[ 4.426362] gpiod_direction_output+0x34/0x5c (P) +[ 4.431067] gpiod_direction_output+0x18/0x5c (L) +[ 4.435771] dspi_setup+0x220/0x334 + +Fixes: 9e264f3f85a5 ("spi: Replace all spi->chip_select and spi->cs_gpiod references with function call") +Cc: stable@vger.kernel.org +Signed-off-by: Frank Li +Link: https://patch.msgid.link/20241023203032.1388491-1-Frank.Li@nxp.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + drivers/spi/spi-fsl-dspi.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c +index 8318249f8a1f9..bcb0de864d34d 100644 +--- a/drivers/spi/spi-fsl-dspi.c ++++ b/drivers/spi/spi-fsl-dspi.c +@@ -1008,6 +1008,7 @@ static int dspi_setup(struct spi_device *spi) + u32 cs_sck_delay = 0, sck_cs_delay = 0; + struct fsl_dspi_platform_data *pdata; + unsigned char pasc = 0, asc = 0; ++ struct gpio_desc *gpio_cs; + struct chip_data *chip; + unsigned long clkrate; + bool cs = true; +@@ -1073,7 +1074,10 @@ static int dspi_setup(struct spi_device *spi) + chip->ctar_val |= SPI_CTAR_LSBFE; + } + +- gpiod_direction_output(spi_get_csgpiod(spi, 0), false); ++ gpio_cs = spi_get_csgpiod(spi, 0); ++ if (gpio_cs) ++ gpiod_direction_output(gpio_cs, false); ++ + dspi_deassert_cs(spi, &cs); + + spi_set_ctldata(spi, chip); +-- +2.43.0 + diff --git a/queue-6.6/vmscan-migrate-fix-page-count-imbalance-on-node-stat.patch b/queue-6.6/vmscan-migrate-fix-page-count-imbalance-on-node-stat.patch new file mode 100644 index 00000000000..1a5d53d2c8a --- /dev/null +++ b/queue-6.6/vmscan-migrate-fix-page-count-imbalance-on-node-stat.patch @@ -0,0 +1,75 @@ +From 0f613f39d2c3ee67bd6192e0630ce07ddf980aa5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 25 Oct 2024 10:17:24 -0400 +Subject: vmscan,migrate: fix page count imbalance on node stats when demoting + pages + +From: Gregory Price + +[ Upstream commit 35e41024c4c2b02ef8207f61b9004f6956cf037b ] + +When numa balancing is enabled with demotion, vmscan will call +migrate_pages when shrinking LRUs. migrate_pages will decrement the +the node's isolated page count, leading to an imbalanced count when +invoked from (MG)LRU code. + +The result is dmesg output like such: + +$ cat /proc/sys/vm/stat_refresh + +[77383.088417] vmstat_refresh: nr_isolated_anon -103212 +[77383.088417] vmstat_refresh: nr_isolated_file -899642 + +This negative value may impact compaction and reclaim throttling. + +The following path produces the decrement: + +shrink_folio_list + demote_folio_list + migrate_pages + migrate_pages_batch + migrate_folio_move + migrate_folio_done + mod_node_page_state(-ve) <- decrement + +This path happens for SUCCESSFUL migrations, not failures. Typically +callers to migrate_pages are required to handle putback/accounting for +failures, but this is already handled in the shrink code. + +When accounting for migrations, instead do not decrement the count when +the migration reason is MR_DEMOTION. As of v6.11, this demotion logic +is the only source of MR_DEMOTION. + +Link: https://lkml.kernel.org/r/20241025141724.17927-1-gourry@gourry.net +Fixes: 26aa2d199d6f ("mm/migrate: demote pages during reclaim") +Signed-off-by: Gregory Price +Reviewed-by: Yang Shi +Reviewed-by: Davidlohr Bueso +Reviewed-by: Shakeel Butt +Reviewed-by: "Huang, Ying" +Reviewed-by: Oscar Salvador +Cc: Dave Hansen +Cc: Wei Xu +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Sasha Levin +--- + mm/migrate.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/mm/migrate.c b/mm/migrate.c +index 5d7d39b1c0699..c5ed8caf6a406 100644 +--- a/mm/migrate.c ++++ b/mm/migrate.c +@@ -1093,7 +1093,7 @@ static void migrate_folio_done(struct folio *src, + * not accounted to NR_ISOLATED_*. They can be recognized + * as __PageMovable + */ +- if (likely(!__folio_test_movable(src))) ++ if (likely(!__folio_test_movable(src)) && reason != MR_DEMOTION) + mod_node_page_state(folio_pgdat(src), NR_ISOLATED_ANON + + folio_is_file_lru(src), -folio_nr_pages(src)); + +-- +2.43.0 + diff --git a/queue-6.6/x86-traps-enable-ubsan-traps-on-x86.patch b/queue-6.6/x86-traps-enable-ubsan-traps-on-x86.patch new file mode 100644 index 00000000000..f900f424976 --- /dev/null +++ b/queue-6.6/x86-traps-enable-ubsan-traps-on-x86.patch @@ -0,0 +1,195 @@ +From 522a9a6fd9f1cafc6115082398383ec1a79a82a6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 24 Jul 2024 00:01:55 +0000 +Subject: x86/traps: Enable UBSAN traps on x86 + +From: Gatlin Newhouse + +[ Upstream commit 7424fc6b86c8980a87169e005f5cd4438d18efe6 ] + +Currently ARM64 extracts which specific sanitizer has caused a trap via +encoded data in the trap instruction. Clang on x86 currently encodes the +same data in the UD1 instruction but x86 handle_bug() and +is_valid_bugaddr() currently only look at UD2. + +Bring x86 to parity with ARM64, similar to commit 25b84002afb9 ("arm64: +Support Clang UBSAN trap codes for better reporting"). See the llvm +links for information about the code generation. + +Enable the reporting of UBSAN sanitizer details on x86 compiled with clang +when CONFIG_UBSAN_TRAP=y by analysing UD1 and retrieving the type immediate +which is encoded by the compiler after the UD1. + +[ tglx: Simplified it by moving the printk() into handle_bug() ] + +Signed-off-by: Gatlin Newhouse +Signed-off-by: Thomas Gleixner +Acked-by: Peter Zijlstra (Intel) +Cc: Kees Cook +Link: https://lore.kernel.org/all/20240724000206.451425-1-gatlin.newhouse@gmail.com +Link: https://github.com/llvm/llvm-project/commit/c5978f42ec8e9#diff-bb68d7cd885f41cfc35843998b0f9f534adb60b415f647109e597ce448e92d9f +Link: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86InstrSystem.td#L27 +Stable-dep-of: 1db272864ff2 ("x86/traps: move kmsan check after instrumentation_begin") +Signed-off-by: Sasha Levin +--- + arch/x86/include/asm/bug.h | 12 ++++++++ + arch/x86/kernel/traps.c | 59 ++++++++++++++++++++++++++++++++++---- + include/linux/ubsan.h | 5 ++++ + lib/Kconfig.ubsan | 4 +-- + 4 files changed, 73 insertions(+), 7 deletions(-) + +diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h +index a3ec87d198ac8..806649c7f23dc 100644 +--- a/arch/x86/include/asm/bug.h ++++ b/arch/x86/include/asm/bug.h +@@ -13,6 +13,18 @@ + #define INSN_UD2 0x0b0f + #define LEN_UD2 2 + ++/* ++ * In clang we have UD1s reporting UBSAN failures on X86, 64 and 32bit. ++ */ ++#define INSN_ASOP 0x67 ++#define OPCODE_ESCAPE 0x0f ++#define SECOND_BYTE_OPCODE_UD1 0xb9 ++#define SECOND_BYTE_OPCODE_UD2 0x0b ++ ++#define BUG_NONE 0xffff ++#define BUG_UD1 0xfffe ++#define BUG_UD2 0xfffd ++ + #ifdef CONFIG_GENERIC_BUG + + #ifdef CONFIG_X86_32 +diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c +index c876f1d36a81a..840a3b2d24779 100644 +--- a/arch/x86/kernel/traps.c ++++ b/arch/x86/kernel/traps.c +@@ -41,6 +41,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -89,6 +90,47 @@ __always_inline int is_valid_bugaddr(unsigned long addr) + return *(unsigned short *)addr == INSN_UD2; + } + ++/* ++ * Check for UD1 or UD2, accounting for Address Size Override Prefixes. ++ * If it's a UD1, get the ModRM byte to pass along to UBSan. ++ */ ++__always_inline int decode_bug(unsigned long addr, u32 *imm) ++{ ++ u8 v; ++ ++ if (addr < TASK_SIZE_MAX) ++ return BUG_NONE; ++ ++ v = *(u8 *)(addr++); ++ if (v == INSN_ASOP) ++ v = *(u8 *)(addr++); ++ if (v != OPCODE_ESCAPE) ++ return BUG_NONE; ++ ++ v = *(u8 *)(addr++); ++ if (v == SECOND_BYTE_OPCODE_UD2) ++ return BUG_UD2; ++ ++ if (!IS_ENABLED(CONFIG_UBSAN_TRAP) || v != SECOND_BYTE_OPCODE_UD1) ++ return BUG_NONE; ++ ++ /* Retrieve the immediate (type value) for the UBSAN UD1 */ ++ v = *(u8 *)(addr++); ++ if (X86_MODRM_RM(v) == 4) ++ addr++; ++ ++ *imm = 0; ++ if (X86_MODRM_MOD(v) == 1) ++ *imm = *(u8 *)addr; ++ else if (X86_MODRM_MOD(v) == 2) ++ *imm = *(u32 *)addr; ++ else ++ WARN_ONCE(1, "Unexpected MODRM_MOD: %u\n", X86_MODRM_MOD(v)); ++ ++ return BUG_UD1; ++} ++ ++ + static nokprobe_inline int + do_trap_no_signal(struct task_struct *tsk, int trapnr, const char *str, + struct pt_regs *regs, long error_code) +@@ -214,6 +256,8 @@ static inline void handle_invalid_op(struct pt_regs *regs) + static noinstr bool handle_bug(struct pt_regs *regs) + { + bool handled = false; ++ int ud_type; ++ u32 imm; + + /* + * Normally @regs are unpoisoned by irqentry_enter(), but handle_bug() +@@ -221,7 +265,8 @@ static noinstr bool handle_bug(struct pt_regs *regs) + * irqentry_enter(). + */ + kmsan_unpoison_entry_regs(regs); +- if (!is_valid_bugaddr(regs->ip)) ++ ud_type = decode_bug(regs->ip, &imm); ++ if (ud_type == BUG_NONE) + return handled; + + /* +@@ -234,10 +279,14 @@ static noinstr bool handle_bug(struct pt_regs *regs) + */ + if (regs->flags & X86_EFLAGS_IF) + raw_local_irq_enable(); +- if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN || +- handle_cfi_failure(regs) == BUG_TRAP_TYPE_WARN) { +- regs->ip += LEN_UD2; +- handled = true; ++ if (ud_type == BUG_UD2) { ++ if (report_bug(regs->ip, regs) == BUG_TRAP_TYPE_WARN || ++ handle_cfi_failure(regs) == BUG_TRAP_TYPE_WARN) { ++ regs->ip += LEN_UD2; ++ handled = true; ++ } ++ } else if (IS_ENABLED(CONFIG_UBSAN_TRAP)) { ++ pr_crit("%s at %pS\n", report_ubsan_failure(regs, imm), (void *)regs->ip); + } + if (regs->flags & X86_EFLAGS_IF) + raw_local_irq_disable(); +diff --git a/include/linux/ubsan.h b/include/linux/ubsan.h +index bff7445498ded..d8219cbe09ff8 100644 +--- a/include/linux/ubsan.h ++++ b/include/linux/ubsan.h +@@ -4,6 +4,11 @@ + + #ifdef CONFIG_UBSAN_TRAP + const char *report_ubsan_failure(struct pt_regs *regs, u32 check_type); ++#else ++static inline const char *report_ubsan_failure(struct pt_regs *regs, u32 check_type) ++{ ++ return NULL; ++} + #endif + + #endif +diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan +index 59e21bfec188c..f43bcac47c0ab 100644 +--- a/lib/Kconfig.ubsan ++++ b/lib/Kconfig.ubsan +@@ -28,8 +28,8 @@ config UBSAN_TRAP + + Also note that selecting Y will cause your kernel to Oops + with an "illegal instruction" error with no further details +- when a UBSAN violation occurs. (Except on arm64, which will +- report which Sanitizer failed.) This may make it hard to ++ when a UBSAN violation occurs. (Except on arm64 and x86, which ++ will report which Sanitizer failed.) This may make it hard to + determine whether an Oops was caused by UBSAN or to figure + out the details of a UBSAN violation. It makes the kernel log + output less useful for bug reports. +-- +2.43.0 + diff --git a/queue-6.6/x86-traps-move-kmsan-check-after-instrumentation_beg.patch b/queue-6.6/x86-traps-move-kmsan-check-after-instrumentation_beg.patch new file mode 100644 index 00000000000..850b84fca7f --- /dev/null +++ b/queue-6.6/x86-traps-move-kmsan-check-after-instrumentation_beg.patch @@ -0,0 +1,78 @@ +From 5e5fc45d8409b1e4c901a04615d9979e74720097 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 16 Oct 2024 20:24:07 +0500 +Subject: x86/traps: move kmsan check after instrumentation_begin + +From: Sabyrzhan Tasbolatov + +[ Upstream commit 1db272864ff250b5e607283eaec819e1186c8e26 ] + +During x86_64 kernel build with CONFIG_KMSAN, the objtool warns following: + + AR built-in.a + AR vmlinux.a + LD vmlinux.o +vmlinux.o: warning: objtool: handle_bug+0x4: call to + kmsan_unpoison_entry_regs() leaves .noinstr.text section + OBJCOPY modules.builtin.modinfo + GEN modules.builtin + MODPOST Module.symvers + CC .vmlinux.export.o + +Moving kmsan_unpoison_entry_regs() _after_ instrumentation_begin() fixes +the warning. + +There is decode_bug(regs->ip, &imm) is left before KMSAN unpoisoining, but +it has the return condition and if we include it after +instrumentation_begin() it results the warning "return with +instrumentation enabled", hence, I'm concerned that regs will not be KMSAN +unpoisoned if `ud_type == BUG_NONE` is true. + +Link: https://lkml.kernel.org/r/20241016152407.3149001-1-snovitoll@gmail.com +Fixes: ba54d194f8da ("x86/traps: avoid KMSAN bugs originating from handle_bug()") +Signed-off-by: Sabyrzhan Tasbolatov +Reviewed-by: Alexander Potapenko +Cc: Borislav Petkov (AMD) +Cc: Dave Hansen +Cc: Ingo Molnar +Cc: Thomas Gleixner +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/traps.c | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c +index 840a3b2d24779..37b8e20c03a9f 100644 +--- a/arch/x86/kernel/traps.c ++++ b/arch/x86/kernel/traps.c +@@ -259,12 +259,6 @@ static noinstr bool handle_bug(struct pt_regs *regs) + int ud_type; + u32 imm; + +- /* +- * Normally @regs are unpoisoned by irqentry_enter(), but handle_bug() +- * is a rare case that uses @regs without passing them to +- * irqentry_enter(). +- */ +- kmsan_unpoison_entry_regs(regs); + ud_type = decode_bug(regs->ip, &imm); + if (ud_type == BUG_NONE) + return handled; +@@ -273,6 +267,12 @@ static noinstr bool handle_bug(struct pt_regs *regs) + * All lies, just get the WARN/BUG out. + */ + instrumentation_begin(); ++ /* ++ * Normally @regs are unpoisoned by irqentry_enter(), but handle_bug() ++ * is a rare case that uses @regs without passing them to ++ * irqentry_enter(). ++ */ ++ kmsan_unpoison_entry_regs(regs); + /* + * Since we're emulating a CALL with exceptions, restore the interrupt + * state to what it was at the exception site. +-- +2.43.0 + diff --git a/queue-6.6/xfs-fix-finding-a-last-resort-ag-in-xfs_filestream_p.patch b/queue-6.6/xfs-fix-finding-a-last-resort-ag-in-xfs_filestream_p.patch new file mode 100644 index 00000000000..be523af7c34 --- /dev/null +++ b/queue-6.6/xfs-fix-finding-a-last-resort-ag-in-xfs_filestream_p.patch @@ -0,0 +1,121 @@ +From 889354daf8c617cf458150b8c174f51032f7f7d2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 23 Oct 2024 15:37:22 +0200 +Subject: xfs: fix finding a last resort AG in xfs_filestream_pick_ag + +From: Christoph Hellwig + +[ Upstream commit dc60992ce76fbc2f71c2674f435ff6bde2108028 ] + +When the main loop in xfs_filestream_pick_ag fails to find a suitable +AG it tries to just pick the online AG. But the loop for that uses +args->pag as loop iterator while the later code expects pag to be +set. Fix this by reusing the max_pag case for this last resort, and +also add a check for impossible case of no AG just to make sure that +the uninitialized pag doesn't even escape in theory. + +Reported-by: syzbot+4125a3c514e3436a02e6@syzkaller.appspotmail.com +Signed-off-by: Christoph Hellwig +Tested-by: syzbot+4125a3c514e3436a02e6@syzkaller.appspotmail.com +Fixes: f8f1ed1ab3baba ("xfs: return a referenced perag from filestreams allocator") +Cc: # v6.3 +Reviewed-by: Darrick J. Wong +Signed-off-by: Carlos Maiolino +Signed-off-by: Sasha Levin +--- + fs/xfs/xfs_filestream.c | 23 ++++++++++++----------- + fs/xfs/xfs_trace.h | 15 +++++---------- + 2 files changed, 17 insertions(+), 21 deletions(-) + +diff --git a/fs/xfs/xfs_filestream.c b/fs/xfs/xfs_filestream.c +index 2fc98d3137086..f62b023f274e9 100644 +--- a/fs/xfs/xfs_filestream.c ++++ b/fs/xfs/xfs_filestream.c +@@ -64,7 +64,7 @@ xfs_filestream_pick_ag( + struct xfs_perag *pag; + struct xfs_perag *max_pag = NULL; + xfs_extlen_t minlen = *longest; +- xfs_extlen_t free = 0, minfree, maxfree = 0; ++ xfs_extlen_t minfree, maxfree = 0; + xfs_agnumber_t agno; + bool first_pass = true; + int err; +@@ -107,7 +107,6 @@ xfs_filestream_pick_ag( + !(flags & XFS_PICK_USERDATA) || + (flags & XFS_PICK_LOWSPACE))) { + /* Break out, retaining the reference on the AG. */ +- free = pag->pagf_freeblks; + break; + } + } +@@ -150,23 +149,25 @@ xfs_filestream_pick_ag( + * grab. + */ + if (!max_pag) { +- for_each_perag_wrap(args->mp, 0, start_agno, args->pag) ++ for_each_perag_wrap(args->mp, 0, start_agno, pag) { ++ max_pag = pag; + break; +- atomic_inc(&args->pag->pagf_fstrms); +- *longest = 0; +- } else { +- pag = max_pag; +- free = maxfree; +- atomic_inc(&pag->pagf_fstrms); ++ } ++ ++ /* Bail if there are no AGs at all to select from. */ ++ if (!max_pag) ++ return -ENOSPC; + } ++ ++ pag = max_pag; ++ atomic_inc(&pag->pagf_fstrms); + } else if (max_pag) { + xfs_perag_rele(max_pag); + } + +- trace_xfs_filestream_pick(pag, pino, free); ++ trace_xfs_filestream_pick(pag, pino); + args->pag = pag; + return 0; +- + } + + static struct xfs_inode * +diff --git a/fs/xfs/xfs_trace.h b/fs/xfs/xfs_trace.h +index 3926cf7f2a6ed..d562028281f5c 100644 +--- a/fs/xfs/xfs_trace.h ++++ b/fs/xfs/xfs_trace.h +@@ -672,8 +672,8 @@ DEFINE_FILESTREAM_EVENT(xfs_filestream_lookup); + DEFINE_FILESTREAM_EVENT(xfs_filestream_scan); + + TRACE_EVENT(xfs_filestream_pick, +- TP_PROTO(struct xfs_perag *pag, xfs_ino_t ino, xfs_extlen_t free), +- TP_ARGS(pag, ino, free), ++ TP_PROTO(struct xfs_perag *pag, xfs_ino_t ino), ++ TP_ARGS(pag, ino), + TP_STRUCT__entry( + __field(dev_t, dev) + __field(xfs_ino_t, ino) +@@ -684,14 +684,9 @@ TRACE_EVENT(xfs_filestream_pick, + TP_fast_assign( + __entry->dev = pag->pag_mount->m_super->s_dev; + __entry->ino = ino; +- if (pag) { +- __entry->agno = pag->pag_agno; +- __entry->streams = atomic_read(&pag->pagf_fstrms); +- } else { +- __entry->agno = NULLAGNUMBER; +- __entry->streams = 0; +- } +- __entry->free = free; ++ __entry->agno = pag->pag_agno; ++ __entry->streams = atomic_read(&pag->pagf_fstrms); ++ __entry->free = pag->pagf_freeblks; + ), + TP_printk("dev %d:%d ino 0x%llx agno 0x%x streams %d free %d", + MAJOR(__entry->dev), MINOR(__entry->dev), +-- +2.43.0 +