From a98d97e8afa97d05dd1cd1baae7686cac2ff48e0 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 19 Feb 2024 19:33:46 +0100 Subject: [PATCH] 5.15-stable patches added patches: alsa-hda-conexant-add-quirk-for-sws-js201d.patch drm-prime-support-page-array-4gb.patch hv_netvsc-fix-race-condition-between-netvsc_probe-and-netvsc_remove.patch mmc-slot-gpio-allow-non-sleeping-gpio-ro.patch nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch nilfs2-fix-hang-in-nilfs_lookup_dirty_data_buffers.patch powerpc-64-set-task-pt_regs-link-to-the-lr-value-on-scv-entry.patch ring-buffer-clean-ring_buffer_poll_wait-error-return.patch serial-max310x-fail-probe-if-clock-crystal-is-unstable.patch serial-max310x-improve-crystal-stable-clock-detection.patch serial-max310x-set-default-value-when-reading-clock-ready-bit.patch x86-kconfig-transmeta-crusoe-is-cpu-family-5-not-6.patch x86-mm-ident_map-use-gbpages-only-where-full-gb-page-should-be-mapped.patch --- ...da-conexant-add-quirk-for-sws-js201d.patch | 76 ++++++++ .../drm-prime-support-page-array-4gb.patch | 38 ++++ ...tween-netvsc_probe-and-netvsc_remove.patch | 76 ++++++++ ...slot-gpio-allow-non-sleeping-gpio-ro.patch | 44 +++++ ...block-recovery-for-small-block-sizes.patch | 61 +++++++ ...g-in-nilfs_lookup_dirty_data_buffers.patch | 62 +++++++ ...gs-link-to-the-lr-value-on-scv-entry.patch | 163 ++++++++++++++++++ ...n-ring_buffer_poll_wait-error-return.patch | 41 +++++ ...l-probe-if-clock-crystal-is-unstable.patch | 69 ++++++++ ...prove-crystal-stable-clock-detection.patch | 82 +++++++++ ...t-value-when-reading-clock-ready-bit.patch | 35 ++++ queue-5.15/series | 13 ++ ...ansmeta-crusoe-is-cpu-family-5-not-6.patch | 43 +++++ ...-where-full-gb-page-should-be-mapped.patch | 77 +++++++++ 14 files changed, 880 insertions(+) create mode 100644 queue-5.15/alsa-hda-conexant-add-quirk-for-sws-js201d.patch create mode 100644 queue-5.15/drm-prime-support-page-array-4gb.patch create mode 100644 queue-5.15/hv_netvsc-fix-race-condition-between-netvsc_probe-and-netvsc_remove.patch create mode 100644 queue-5.15/mmc-slot-gpio-allow-non-sleeping-gpio-ro.patch create mode 100644 queue-5.15/nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch create mode 100644 queue-5.15/nilfs2-fix-hang-in-nilfs_lookup_dirty_data_buffers.patch create mode 100644 queue-5.15/powerpc-64-set-task-pt_regs-link-to-the-lr-value-on-scv-entry.patch create mode 100644 queue-5.15/ring-buffer-clean-ring_buffer_poll_wait-error-return.patch create mode 100644 queue-5.15/serial-max310x-fail-probe-if-clock-crystal-is-unstable.patch create mode 100644 queue-5.15/serial-max310x-improve-crystal-stable-clock-detection.patch create mode 100644 queue-5.15/serial-max310x-set-default-value-when-reading-clock-ready-bit.patch create mode 100644 queue-5.15/x86-kconfig-transmeta-crusoe-is-cpu-family-5-not-6.patch create mode 100644 queue-5.15/x86-mm-ident_map-use-gbpages-only-where-full-gb-page-should-be-mapped.patch diff --git a/queue-5.15/alsa-hda-conexant-add-quirk-for-sws-js201d.patch b/queue-5.15/alsa-hda-conexant-add-quirk-for-sws-js201d.patch new file mode 100644 index 00000000000..92a4477d00a --- /dev/null +++ b/queue-5.15/alsa-hda-conexant-add-quirk-for-sws-js201d.patch @@ -0,0 +1,76 @@ +From 4639c5021029d49fd2f97fa8d74731f167f98919 Mon Sep 17 00:00:00 2001 +From: bo liu +Date: Mon, 5 Feb 2024 09:38:02 +0800 +Subject: ALSA: hda/conexant: Add quirk for SWS JS201D + +From: bo liu + +commit 4639c5021029d49fd2f97fa8d74731f167f98919 upstream. + +The SWS JS201D need a different pinconfig from windows driver. +Add a quirk to use a specific pinconfig to SWS JS201D. + +Signed-off-by: bo liu +Cc: +Link: https://lore.kernel.org/r/20240205013802.51907-1-bo.liu@senarytech.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_conexant.c | 18 ++++++++++++++++++ + 1 file changed, 18 insertions(+) + +--- a/sound/pci/hda/patch_conexant.c ++++ b/sound/pci/hda/patch_conexant.c +@@ -344,6 +344,7 @@ enum { + CXT_FIXUP_HP_ZBOOK_MUTE_LED, + CXT_FIXUP_HEADSET_MIC, + CXT_FIXUP_HP_MIC_NO_PRESENCE, ++ CXT_PINCFG_SWS_JS201D, + }; + + /* for hda_fixup_thinkpad_acpi() */ +@@ -841,6 +842,17 @@ static const struct hda_pintbl cxt_pincf + {} + }; + ++/* SuoWoSi/South-holding JS201D with sn6140 */ ++static const struct hda_pintbl cxt_pincfg_sws_js201d[] = { ++ { 0x16, 0x03211040 }, /* hp out */ ++ { 0x17, 0x91170110 }, /* SPK/Class_D */ ++ { 0x18, 0x95a70130 }, /* Internal mic */ ++ { 0x19, 0x03a11020 }, /* Headset Mic */ ++ { 0x1a, 0x40f001f0 }, /* Not used */ ++ { 0x21, 0x40f001f0 }, /* Not used */ ++ {} ++}; ++ + static const struct hda_fixup cxt_fixups[] = { + [CXT_PINCFG_LENOVO_X200] = { + .type = HDA_FIXUP_PINS, +@@ -996,6 +1008,10 @@ static const struct hda_fixup cxt_fixups + .chained = true, + .chain_id = CXT_FIXUP_HEADSET_MIC, + }, ++ [CXT_PINCFG_SWS_JS201D] = { ++ .type = HDA_FIXUP_PINS, ++ .v.pins = cxt_pincfg_sws_js201d, ++ }, + }; + + static const struct snd_pci_quirk cxt5045_fixups[] = { +@@ -1069,6 +1085,7 @@ static const struct snd_pci_quirk cxt506 + SND_PCI_QUIRK(0x103c, 0x8457, "HP Z2 G4 mini", CXT_FIXUP_HP_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x103c, 0x8458, "HP Z2 G4 mini premium", CXT_FIXUP_HP_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1043, 0x138d, "Asus", CXT_FIXUP_HEADPHONE_MIC_PIN), ++ SND_PCI_QUIRK(0x14f1, 0x0265, "SWS JS201D", CXT_PINCFG_SWS_JS201D), + SND_PCI_QUIRK(0x152d, 0x0833, "OLPC XO-1.5", CXT_FIXUP_OLPC_XO), + SND_PCI_QUIRK(0x17aa, 0x20f2, "Lenovo T400", CXT_PINCFG_LENOVO_TP410), + SND_PCI_QUIRK(0x17aa, 0x215e, "Lenovo T410", CXT_PINCFG_LENOVO_TP410), +@@ -1109,6 +1126,7 @@ static const struct hda_model_fixup cxt5 + { .id = CXT_FIXUP_HP_ZBOOK_MUTE_LED, .name = "hp-zbook-mute-led" }, + { .id = CXT_FIXUP_HP_MIC_NO_PRESENCE, .name = "hp-mic-fix" }, + { .id = CXT_PINCFG_LENOVO_NOTEBOOK, .name = "lenovo-20149" }, ++ { .id = CXT_PINCFG_SWS_JS201D, .name = "sws-js201d" }, + {} + }; + diff --git a/queue-5.15/drm-prime-support-page-array-4gb.patch b/queue-5.15/drm-prime-support-page-array-4gb.patch new file mode 100644 index 00000000000..72bfd093f29 --- /dev/null +++ b/queue-5.15/drm-prime-support-page-array-4gb.patch @@ -0,0 +1,38 @@ +From b671cd3d456315f63171a670769356a196cf7fd0 Mon Sep 17 00:00:00 2001 +From: Philip Yang +Date: Mon, 21 Aug 2023 16:02:01 -0400 +Subject: drm/prime: Support page array >= 4GB +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Philip Yang + +commit b671cd3d456315f63171a670769356a196cf7fd0 upstream. + +Without unsigned long typecast, the size is passed in as zero if page +array size >= 4GB, nr_pages >= 0x100000, then sg list converted will +have the first and the last chunk lost. + +Signed-off-by: Philip Yang +Acked-by: Felix Kuehling +Reviewed-by: Christian König +CC: stable@vger.kernel.org +Signed-off-by: Christian König +Link: https://patchwork.freedesktop.org/patch/msgid/20230821200201.24685-1-Philip.Yang@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/drm_prime.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/drm_prime.c ++++ b/drivers/gpu/drm/drm_prime.c +@@ -825,7 +825,7 @@ struct sg_table *drm_prime_pages_to_sg(s + if (max_segment == 0) + max_segment = UINT_MAX; + err = sg_alloc_table_from_pages_segment(sg, pages, nr_pages, 0, +- nr_pages << PAGE_SHIFT, ++ (unsigned long)nr_pages << PAGE_SHIFT, + max_segment, GFP_KERNEL); + if (err) { + kfree(sg); diff --git a/queue-5.15/hv_netvsc-fix-race-condition-between-netvsc_probe-and-netvsc_remove.patch b/queue-5.15/hv_netvsc-fix-race-condition-between-netvsc_probe-and-netvsc_remove.patch new file mode 100644 index 00000000000..eeb99e2f244 --- /dev/null +++ b/queue-5.15/hv_netvsc-fix-race-condition-between-netvsc_probe-and-netvsc_remove.patch @@ -0,0 +1,76 @@ +From e0526ec5360a48ad3ab2e26e802b0532302a7e11 Mon Sep 17 00:00:00 2001 +From: Souradeep Chakrabarti +Date: Tue, 30 Jan 2024 23:35:51 -0800 +Subject: hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove + +From: Souradeep Chakrabarti + +commit e0526ec5360a48ad3ab2e26e802b0532302a7e11 upstream. + +In commit ac5047671758 ("hv_netvsc: Disable NAPI before closing the +VMBus channel"), napi_disable was getting called for all channels, +including all subchannels without confirming if they are enabled or not. + +This caused hv_netvsc getting hung at napi_disable, when netvsc_probe() +has finished running but nvdev->subchan_work has not started yet. +netvsc_subchan_work() -> rndis_set_subchannel() has not created the +sub-channels and because of that netvsc_sc_open() is not running. +netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which +netvsc_subchan_work did not run. + +netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI +cannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the +NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the +opposite. + +Now during netvsc_device_remove(), when napi_disable is called for those +subchannels, napi_disable gets stuck on infinite msleep. + +This fix addresses this problem by ensuring that napi_disable() is not +getting called for non-enabled NAPI struct. +But netif_napi_del() is still necessary for these non-enabled NAPI struct +for cleanup purpose. + +Call trace: +[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002 +[ 654.568030] Call Trace: +[ 654.571221] +[ 654.573790] __schedule+0x2d6/0x960 +[ 654.577733] schedule+0x69/0xf0 +[ 654.581214] schedule_timeout+0x87/0x140 +[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20 +[ 654.590291] msleep+0x2d/0x40 +[ 654.593625] napi_disable+0x2b/0x80 +[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc] +[ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc] +[ 654.611101] ? do_wait_intr+0xb0/0xb0 +[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc] +[ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus] + +Cc: stable@vger.kernel.org +Fixes: ac5047671758 ("hv_netvsc: Disable NAPI before closing the VMBus channel") +Signed-off-by: Souradeep Chakrabarti +Reviewed-by: Dexuan Cui +Reviewed-by: Haiyang Zhang +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/1706686551-28510-1-git-send-email-schakrabarti@linux.microsoft.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/hyperv/netvsc.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/net/hyperv/netvsc.c ++++ b/drivers/net/hyperv/netvsc.c +@@ -710,7 +710,10 @@ void netvsc_device_remove(struct hv_devi + /* Disable NAPI and disassociate its context from the device. */ + for (i = 0; i < net_device->num_chn; i++) { + /* See also vmbus_reset_channel_cb(). */ +- napi_disable(&net_device->chan_table[i].napi); ++ /* only disable enabled NAPI channel */ ++ if (i < ndev->real_num_rx_queues) ++ napi_disable(&net_device->chan_table[i].napi); ++ + netif_napi_del(&net_device->chan_table[i].napi); + } + diff --git a/queue-5.15/mmc-slot-gpio-allow-non-sleeping-gpio-ro.patch b/queue-5.15/mmc-slot-gpio-allow-non-sleeping-gpio-ro.patch new file mode 100644 index 00000000000..25b8288d2c8 --- /dev/null +++ b/queue-5.15/mmc-slot-gpio-allow-non-sleeping-gpio-ro.patch @@ -0,0 +1,44 @@ +From cc9432c4fb159a3913e0ce3173b8218cd5bad2e0 Mon Sep 17 00:00:00 2001 +From: Alexander Stein +Date: Tue, 6 Feb 2024 09:39:12 +0100 +Subject: mmc: slot-gpio: Allow non-sleeping GPIO ro + +From: Alexander Stein + +commit cc9432c4fb159a3913e0ce3173b8218cd5bad2e0 upstream. + +This change uses the appropriate _cansleep or non-sleeping API for +reading GPIO read-only state. This allows users with GPIOs that +never sleepbeing called in atomic context. + +Implement the same mechanism as in commit 52af318c93e97 ("mmc: Allow +non-sleeping GPIO cd"). + +Signed-off-by: Alexander Stein +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20240206083912.2543142-1-alexander.stein@ew.tq-group.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mmc/core/slot-gpio.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/mmc/core/slot-gpio.c ++++ b/drivers/mmc/core/slot-gpio.c +@@ -62,11 +62,15 @@ int mmc_gpio_alloc(struct mmc_host *host + int mmc_gpio_get_ro(struct mmc_host *host) + { + struct mmc_gpio *ctx = host->slot.handler_priv; ++ int cansleep; + + if (!ctx || !ctx->ro_gpio) + return -ENOSYS; + +- return gpiod_get_value_cansleep(ctx->ro_gpio); ++ cansleep = gpiod_cansleep(ctx->ro_gpio); ++ return cansleep ? ++ gpiod_get_value_cansleep(ctx->ro_gpio) : ++ gpiod_get_value(ctx->ro_gpio); + } + EXPORT_SYMBOL(mmc_gpio_get_ro); + diff --git a/queue-5.15/nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch b/queue-5.15/nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch new file mode 100644 index 00000000000..003fd0f53a6 --- /dev/null +++ b/queue-5.15/nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch @@ -0,0 +1,61 @@ +From 67b8bcbaed4777871bb0dcc888fb02a614a98ab1 Mon Sep 17 00:00:00 2001 +From: Ryusuke Konishi +Date: Wed, 24 Jan 2024 21:19:36 +0900 +Subject: nilfs2: fix data corruption in dsync block recovery for small block sizes + +From: Ryusuke Konishi + +commit 67b8bcbaed4777871bb0dcc888fb02a614a98ab1 upstream. + +The helper function nilfs_recovery_copy_block() of +nilfs_recovery_dsync_blocks(), which recovers data from logs created by +data sync writes during a mount after an unclean shutdown, incorrectly +calculates the on-page offset when copying repair data to the file's page +cache. In environments where the block size is smaller than the page +size, this flaw can cause data corruption and leak uninitialized memory +bytes during the recovery process. + +Fix these issues by correcting this byte offset calculation on the page. + +Link: https://lkml.kernel.org/r/20240124121936.10575-1-konishi.ryusuke@gmail.com +Signed-off-by: Ryusuke Konishi +Tested-by: Ryusuke Konishi +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/nilfs2/recovery.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/fs/nilfs2/recovery.c ++++ b/fs/nilfs2/recovery.c +@@ -472,9 +472,10 @@ static int nilfs_prepare_segment_for_rec + + static int nilfs_recovery_copy_block(struct the_nilfs *nilfs, + struct nilfs_recovery_block *rb, +- struct page *page) ++ loff_t pos, struct page *page) + { + struct buffer_head *bh_org; ++ size_t from = pos & ~PAGE_MASK; + void *kaddr; + + bh_org = __bread(nilfs->ns_bdev, rb->blocknr, nilfs->ns_blocksize); +@@ -482,7 +483,7 @@ static int nilfs_recovery_copy_block(str + return -EIO; + + kaddr = kmap_atomic(page); +- memcpy(kaddr + bh_offset(bh_org), bh_org->b_data, bh_org->b_size); ++ memcpy(kaddr + from, bh_org->b_data, bh_org->b_size); + kunmap_atomic(kaddr); + brelse(bh_org); + return 0; +@@ -521,7 +522,7 @@ static int nilfs_recover_dsync_blocks(st + goto failed_inode; + } + +- err = nilfs_recovery_copy_block(nilfs, rb, page); ++ err = nilfs_recovery_copy_block(nilfs, rb, pos, page); + if (unlikely(err)) + goto failed_page; + diff --git a/queue-5.15/nilfs2-fix-hang-in-nilfs_lookup_dirty_data_buffers.patch b/queue-5.15/nilfs2-fix-hang-in-nilfs_lookup_dirty_data_buffers.patch new file mode 100644 index 00000000000..63db9f724c1 --- /dev/null +++ b/queue-5.15/nilfs2-fix-hang-in-nilfs_lookup_dirty_data_buffers.patch @@ -0,0 +1,62 @@ +From 38296afe3c6ee07319e01bb249aa4bb47c07b534 Mon Sep 17 00:00:00 2001 +From: Ryusuke Konishi +Date: Wed, 31 Jan 2024 23:56:57 +0900 +Subject: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() + +From: Ryusuke Konishi + +commit 38296afe3c6ee07319e01bb249aa4bb47c07b534 upstream. + +Syzbot reported a hang issue in migrate_pages_batch() called by mbind() +and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. + +While migrate_pages_batch() locks a folio and waits for the writeback to +complete, the log writer thread that should bring the writeback to +completion picks up the folio being written back in +nilfs_lookup_dirty_data_buffers() that it calls for subsequent log +creation and was trying to lock the folio. Thus causing a deadlock. + +In the first place, it is unexpected that folios/pages in the middle of +writeback will be updated and become dirty. Nilfs2 adds a checksum to +verify the validity of the log being written and uses it for recovery at +mount, so data changes during writeback are suppressed. Since this is +broken, an unclean shutdown could potentially cause recovery to fail. + +Investigation revealed that the root cause is that the wait for writeback +completion in nilfs_page_mkwrite() is conditional, and if the backing +device does not require stable writes, data may be modified without +waiting. + +Fix these issues by making nilfs_page_mkwrite() wait for writeback to +finish regardless of the stable write requirement of the backing device. + +Link: https://lkml.kernel.org/r/20240131145657.4209-1-konishi.ryusuke@gmail.com +Fixes: 1d1d1a767206 ("mm: only enforce stable page writes if the backing device requires it") +Signed-off-by: Ryusuke Konishi +Reported-by: syzbot+ee2ae68da3b22d04cd8d@syzkaller.appspotmail.com +Closes: https://lkml.kernel.org/r/00000000000047d819061004ad6c@google.com +Tested-by: Ryusuke Konishi +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/nilfs2/file.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/fs/nilfs2/file.c ++++ b/fs/nilfs2/file.c +@@ -105,7 +105,13 @@ static vm_fault_t nilfs_page_mkwrite(str + nilfs_transaction_commit(inode->i_sb); + + mapped: +- wait_for_stable_page(page); ++ /* ++ * Since checksumming including data blocks is performed to determine ++ * the validity of the log to be written and used for recovery, it is ++ * necessary to wait for writeback to finish here, regardless of the ++ * stable write requirement of the backing device. ++ */ ++ wait_on_page_writeback(page); + out: + sb_end_pagefault(inode->i_sb); + return block_page_mkwrite_return(ret); diff --git a/queue-5.15/powerpc-64-set-task-pt_regs-link-to-the-lr-value-on-scv-entry.patch b/queue-5.15/powerpc-64-set-task-pt_regs-link-to-the-lr-value-on-scv-entry.patch new file mode 100644 index 00000000000..e11a59642b9 --- /dev/null +++ b/queue-5.15/powerpc-64-set-task-pt_regs-link-to-the-lr-value-on-scv-entry.patch @@ -0,0 +1,163 @@ +From aad98efd0b121f63a2e1c221dcb4d4850128c697 Mon Sep 17 00:00:00 2001 +From: Naveen N Rao +Date: Fri, 2 Feb 2024 21:13:16 +0530 +Subject: powerpc/64: Set task pt_regs->link to the LR value on scv entry + +From: Naveen N Rao + +commit aad98efd0b121f63a2e1c221dcb4d4850128c697 upstream. + +Nysal reported that userspace backtraces are missing in offcputime bcc +tool. As an example: + $ sudo ./bcc/tools/offcputime.py -uU + Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end. + + ^C + write + - python (9107) + 8 + + write + - sudo (9105) + 9 + + mmap + - python (9107) + 16 + + clock_nanosleep + - multipathd (697) + 3001604 + +The offcputime bcc tool attaches a bpf program to a kprobe on +finish_task_switch(), which is usually hit on a syscall from userspace. +With the switch to system call vectored, we started setting +pt_regs->link to zero. This is because system call vectored behaves like +a function call with LR pointing to the system call return address, and +with no modification to SRR0/SRR1. The LR value does indicate our next +instruction, so it is being saved as pt_regs->nip, and pt_regs->link is +being set to zero. This is not a problem by itself, but BPF uses perf +callchain infrastructure for capturing stack traces, and that stores LR +as the second entry in the stack trace. perf has code to cope with the +second entry being zero, and skips over it. However, generic userspace +unwinders assume that a zero entry indicates end of the stack trace, +resulting in a truncated userspace stack trace. + +Rather than fixing all userspace unwinders to ignore/skip past the +second entry, store the real LR value in pt_regs->link so that there +continues to be a valid, though duplicate entry in the stack trace. + +With this change: + $ sudo ./bcc/tools/offcputime.py -uU + Tracing off-CPU time (us) of user threads by user stack... Hit Ctrl-C to end. + + ^C + write + write + [unknown] + [unknown] + [unknown] + [unknown] + [unknown] + PyObject_VectorcallMethod + [unknown] + [unknown] + PyObject_CallOneArg + PyFile_WriteObject + PyFile_WriteString + [unknown] + [unknown] + PyObject_Vectorcall + _PyEval_EvalFrameDefault + PyEval_EvalCode + [unknown] + [unknown] + [unknown] + _PyRun_SimpleFileObject + _PyRun_AnyFileObject + Py_RunMain + [unknown] + Py_BytesMain + [unknown] + __libc_start_main + - python (1293) + 7 + + write + write + [unknown] + sudo_ev_loop_v1 + sudo_ev_dispatch_v1 + [unknown] + [unknown] + [unknown] + [unknown] + __libc_start_main + - sudo (1291) + 7 + + syscall + syscall + bpf_open_perf_buffer_opts + [unknown] + [unknown] + [unknown] + [unknown] + _PyObject_MakeTpCall + PyObject_Vectorcall + _PyEval_EvalFrameDefault + PyEval_EvalCode + [unknown] + [unknown] + [unknown] + _PyRun_SimpleFileObject + _PyRun_AnyFileObject + Py_RunMain + [unknown] + Py_BytesMain + [unknown] + __libc_start_main + - python (1293) + 11 + + clock_nanosleep + clock_nanosleep + nanosleep + sleep + [unknown] + [unknown] + __clone + - multipathd (698) + 3001661 + +Fixes: 7fa95f9adaee ("powerpc/64s: system call support for scv/rfscv instructions") +Cc: stable@vger.kernel.org +Reported-by: "Nysal Jan K.A" +Signed-off-by: Naveen N Rao +Signed-off-by: Michael Ellerman +Link: https://msgid.link/20240202154316.395276-1-naveen@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/powerpc/kernel/interrupt_64.S | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/powerpc/kernel/interrupt_64.S ++++ b/arch/powerpc/kernel/interrupt_64.S +@@ -62,7 +62,8 @@ _ASM_NOKPROBE_SYMBOL(system_call_vectore + mr r10,r1 + ld r1,PACAKSAVE(r13) + std r10,0(r1) +- std r11,_NIP(r1) ++ std r11,_LINK(r1) ++ std r11,_NIP(r1) /* Saved LR is also the next instruction */ + std r12,_MSR(r1) + std r0,GPR0(r1) + std r10,GPR1(r1) +@@ -85,7 +86,6 @@ _ASM_NOKPROBE_SYMBOL(system_call_vectore + std r9,GPR13(r1) + SAVE_NVGPRS(r1) + std r11,_XER(r1) +- std r11,_LINK(r1) + std r11,_CTR(r1) + + li r11,\trapnr diff --git a/queue-5.15/ring-buffer-clean-ring_buffer_poll_wait-error-return.patch b/queue-5.15/ring-buffer-clean-ring_buffer_poll_wait-error-return.patch new file mode 100644 index 00000000000..25e4824809f --- /dev/null +++ b/queue-5.15/ring-buffer-clean-ring_buffer_poll_wait-error-return.patch @@ -0,0 +1,41 @@ +From 66bbea9ed6446b8471d365a22734dc00556c4785 Mon Sep 17 00:00:00 2001 +From: Vincent Donnefort +Date: Wed, 31 Jan 2024 14:09:55 +0000 +Subject: ring-buffer: Clean ring_buffer_poll_wait() error return + +From: Vincent Donnefort + +commit 66bbea9ed6446b8471d365a22734dc00556c4785 upstream. + +The return type for ring_buffer_poll_wait() is __poll_t. This is behind +the scenes an unsigned where we can set event bits. In case of a +non-allocated CPU, we do return instead -EINVAL (0xffffffea). Lucky us, +this ends up setting few error bits (EPOLLERR | EPOLLHUP | EPOLLNVAL), so +user-space at least is aware something went wrong. + +Nonetheless, this is an incorrect code. Replace that -EINVAL with a +proper EPOLLERR to clean that output. As this doesn't change the +behaviour, there's no need to treat this change as a bug fix. + +Link: https://lore.kernel.org/linux-trace-kernel/20240131140955.3322792-1-vdonnefort@google.com + +Cc: stable@vger.kernel.org +Fixes: 6721cb6002262 ("ring-buffer: Do not poll non allocated cpu buffers") +Signed-off-by: Vincent Donnefort +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/ring_buffer.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/trace/ring_buffer.c ++++ b/kernel/trace/ring_buffer.c +@@ -1061,7 +1061,7 @@ __poll_t ring_buffer_poll_wait(struct tr + full = 0; + } else { + if (!cpumask_test_cpu(cpu, buffer->cpumask)) +- return -EINVAL; ++ return EPOLLERR; + + cpu_buffer = buffer->buffers[cpu]; + work = &cpu_buffer->irq_work; diff --git a/queue-5.15/serial-max310x-fail-probe-if-clock-crystal-is-unstable.patch b/queue-5.15/serial-max310x-fail-probe-if-clock-crystal-is-unstable.patch new file mode 100644 index 00000000000..7b1ca3d5e21 --- /dev/null +++ b/queue-5.15/serial-max310x-fail-probe-if-clock-crystal-is-unstable.patch @@ -0,0 +1,69 @@ +From 8afa6c6decea37e7cb473d2c60473f37f46cea35 Mon Sep 17 00:00:00 2001 +From: Hugo Villeneuve +Date: Tue, 16 Jan 2024 16:30:00 -0500 +Subject: serial: max310x: fail probe if clock crystal is unstable +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Hugo Villeneuve + +commit 8afa6c6decea37e7cb473d2c60473f37f46cea35 upstream. + +A stable clock is really required in order to use this UART, so log an +error message and bail out if the chip reports that the clock is not +stable. + +Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness") +Cc: stable@vger.kernel.org +Suggested-by: Jan Kundrát +Link: https://www.spinics.net/lists/linux-serial/msg35773.html +Signed-off-by: Hugo Villeneuve +Link: https://lore.kernel.org/r/20240116213001.3691629-4-hugo@hugovil.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/max310x.c | 12 +++++++++--- + 1 file changed, 9 insertions(+), 3 deletions(-) + +--- a/drivers/tty/serial/max310x.c ++++ b/drivers/tty/serial/max310x.c +@@ -556,7 +556,7 @@ static int max310x_update_best_err(unsig + return 1; + } + +-static u32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s, ++static s32 max310x_set_ref_clk(struct device *dev, struct max310x_port *s, + unsigned long freq, bool xtal) + { + unsigned int div, clksrc, pllcfg = 0; +@@ -626,7 +626,8 @@ static u32 max310x_set_ref_clk(struct de + } while (!stable && (++try < MAX310X_XTAL_WAIT_RETRIES)); + + if (!stable) +- dev_warn(dev, "clock is not stable yet\n"); ++ return dev_err_probe(dev, -EAGAIN, ++ "clock is not stable\n"); + } + + return bestfreq; +@@ -1266,7 +1267,7 @@ static int max310x_probe(struct device * + { + int i, ret, fmin, fmax, freq; + struct max310x_port *s; +- u32 uartclk = 0; ++ s32 uartclk = 0; + bool xtal; + + if (IS_ERR(regmap)) +@@ -1346,6 +1347,11 @@ static int max310x_probe(struct device * + } + + uartclk = max310x_set_ref_clk(dev, s, freq, xtal); ++ if (uartclk < 0) { ++ ret = uartclk; ++ goto out_uart; ++ } ++ + dev_dbg(dev, "Reference clock set to %i Hz\n", uartclk); + + for (i = 0; i < devtype->nr; i++) { diff --git a/queue-5.15/serial-max310x-improve-crystal-stable-clock-detection.patch b/queue-5.15/serial-max310x-improve-crystal-stable-clock-detection.patch new file mode 100644 index 00000000000..3be8030fb32 --- /dev/null +++ b/queue-5.15/serial-max310x-improve-crystal-stable-clock-detection.patch @@ -0,0 +1,82 @@ +From 93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 Mon Sep 17 00:00:00 2001 +From: Hugo Villeneuve +Date: Tue, 16 Jan 2024 16:29:59 -0500 +Subject: serial: max310x: improve crystal stable clock detection +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Hugo Villeneuve + +commit 93cd256ab224c2519e7c4e5f58bb4f1ac2bf0965 upstream. + +Some people are seeing a warning similar to this when using a crystal: + + max310x 11-006c: clock is not stable yet + +The datasheet doesn't mention the maximum time to wait for the clock to be +stable when using a crystal, and it seems that the 10ms delay in the driver +is not always sufficient. + +Jan Kundrát reported that it took three tries (each separated by 10ms) to +get a stable clock. + +Modify behavior to check stable clock ready bit multiple times (20), and +waiting 10ms between each try. + +Note: the first draft of the driver originally used a 50ms delay, without +checking the clock stable bit. +Then a loop with 1000 retries was implemented, each time reading the clock +stable bit. + +Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness") +Cc: stable@vger.kernel.org +Suggested-by: Jan Kundrát +Link: https://www.spinics.net/lists/linux-serial/msg35773.html +Link: https://lore.kernel.org/all/20240110174015.6f20195fde08e5c9e64e5675@hugovil.com/raw +Link: https://github.com/boundarydevices/linux/commit/e5dfe3e4a751392515d78051973190301a37ca9a +Signed-off-by: Hugo Villeneuve +Link: https://lore.kernel.org/r/20240116213001.3691629-3-hugo@hugovil.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/max310x.c | 21 ++++++++++++++++----- + 1 file changed, 16 insertions(+), 5 deletions(-) + +--- a/drivers/tty/serial/max310x.c ++++ b/drivers/tty/serial/max310x.c +@@ -235,6 +235,10 @@ + #define MAX310x_REV_MASK (0xf8) + #define MAX310X_WRITE_BIT 0x80 + ++/* Crystal-related definitions */ ++#define MAX310X_XTAL_WAIT_RETRIES 20 /* Number of retries */ ++#define MAX310X_XTAL_WAIT_DELAY_MS 10 /* Delay between retries */ ++ + /* MAX3107 specific */ + #define MAX3107_REV_ID (0xa0) + +@@ -610,12 +614,19 @@ static u32 max310x_set_ref_clk(struct de + + /* Wait for crystal */ + if (xtal) { +- unsigned int val = 0; +- msleep(10); +- regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val); +- if (!(val & MAX310X_STS_CLKREADY_BIT)) { ++ bool stable = false; ++ unsigned int try = 0, val = 0; ++ ++ do { ++ msleep(MAX310X_XTAL_WAIT_DELAY_MS); ++ regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val); ++ ++ if (val & MAX310X_STS_CLKREADY_BIT) ++ stable = true; ++ } while (!stable && (++try < MAX310X_XTAL_WAIT_RETRIES)); ++ ++ if (!stable) + dev_warn(dev, "clock is not stable yet\n"); +- } + } + + return bestfreq; diff --git a/queue-5.15/serial-max310x-set-default-value-when-reading-clock-ready-bit.patch b/queue-5.15/serial-max310x-set-default-value-when-reading-clock-ready-bit.patch new file mode 100644 index 00000000000..3f27cb8e0f9 --- /dev/null +++ b/queue-5.15/serial-max310x-set-default-value-when-reading-clock-ready-bit.patch @@ -0,0 +1,35 @@ +From 0419373333c2f2024966d36261fd82a453281e80 Mon Sep 17 00:00:00 2001 +From: Hugo Villeneuve +Date: Tue, 16 Jan 2024 16:29:58 -0500 +Subject: serial: max310x: set default value when reading clock ready bit + +From: Hugo Villeneuve + +commit 0419373333c2f2024966d36261fd82a453281e80 upstream. + +If regmap_read() returns a non-zero value, the 'val' variable can be left +uninitialized. + +Clear it before calling regmap_read() to make sure we properly detect +the clock ready bit. + +Fixes: 4cf9a888fd3c ("serial: max310x: Check the clock readiness") +Cc: stable@vger.kernel.org +Signed-off-by: Hugo Villeneuve +Link: https://lore.kernel.org/r/20240116213001.3691629-2-hugo@hugovil.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/max310x.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/serial/max310x.c ++++ b/drivers/tty/serial/max310x.c +@@ -610,7 +610,7 @@ static u32 max310x_set_ref_clk(struct de + + /* Wait for crystal */ + if (xtal) { +- unsigned int val; ++ unsigned int val = 0; + msleep(10); + regmap_read(s->regmap, MAX310X_STS_IRQSTS_REG, &val); + if (!(val & MAX310X_STS_CLKREADY_BIT)) { diff --git a/queue-5.15/series b/queue-5.15/series index 308d34793aa..f2524850be1 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -404,3 +404,16 @@ iio-magnetometer-rm3100-add-boundary-check-for-the-value-read-from-rm3100_reg_tm iio-core-fix-memleak-in-iio_device_register_sysfs.patch iio-accel-bma400-fix-a-compilation-problem.patch media-rc-bpf-attach-detach-requires-write-permission.patch +drm-prime-support-page-array-4gb.patch +hv_netvsc-fix-race-condition-between-netvsc_probe-and-netvsc_remove.patch +ring-buffer-clean-ring_buffer_poll_wait-error-return.patch +serial-max310x-set-default-value-when-reading-clock-ready-bit.patch +serial-max310x-improve-crystal-stable-clock-detection.patch +serial-max310x-fail-probe-if-clock-crystal-is-unstable.patch +powerpc-64-set-task-pt_regs-link-to-the-lr-value-on-scv-entry.patch +x86-kconfig-transmeta-crusoe-is-cpu-family-5-not-6.patch +x86-mm-ident_map-use-gbpages-only-where-full-gb-page-should-be-mapped.patch +mmc-slot-gpio-allow-non-sleeping-gpio-ro.patch +alsa-hda-conexant-add-quirk-for-sws-js201d.patch +nilfs2-fix-data-corruption-in-dsync-block-recovery-for-small-block-sizes.patch +nilfs2-fix-hang-in-nilfs_lookup_dirty_data_buffers.patch diff --git a/queue-5.15/x86-kconfig-transmeta-crusoe-is-cpu-family-5-not-6.patch b/queue-5.15/x86-kconfig-transmeta-crusoe-is-cpu-family-5-not-6.patch new file mode 100644 index 00000000000..1f6890461fe --- /dev/null +++ b/queue-5.15/x86-kconfig-transmeta-crusoe-is-cpu-family-5-not-6.patch @@ -0,0 +1,43 @@ +From f6a1892585cd19e63c4ef2334e26cd536d5b678d Mon Sep 17 00:00:00 2001 +From: Aleksander Mazur +Date: Tue, 23 Jan 2024 14:43:00 +0100 +Subject: x86/Kconfig: Transmeta Crusoe is CPU family 5, not 6 + +From: Aleksander Mazur + +commit f6a1892585cd19e63c4ef2334e26cd536d5b678d upstream. + +The kernel built with MCRUSOE is unbootable on Transmeta Crusoe. It shows +the following error message: + + This kernel requires an i686 CPU, but only detected an i586 CPU. + Unable to boot - please use a kernel appropriate for your CPU. + +Remove MCRUSOE from the condition introduced in commit in Fixes, effectively +changing X86_MINIMUM_CPU_FAMILY back to 5 on that machine, which matches the +CPU family given by CPUID. + + [ bp: Massage commit message. ] + +Fixes: 25d76ac88821 ("x86/Kconfig: Explicitly enumerate i686-class CPUs in Kconfig") +Signed-off-by: Aleksander Mazur +Signed-off-by: Borislav Petkov (AMD) +Acked-by: H. Peter Anvin +Cc: +Link: https://lore.kernel.org/r/20240123134309.1117782-1-deweloper@wp.pl +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/Kconfig.cpu | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/Kconfig.cpu ++++ b/arch/x86/Kconfig.cpu +@@ -379,7 +379,7 @@ config X86_CMOV + config X86_MINIMUM_CPU_FAMILY + int + default "64" if X86_64 +- default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCRUSOE || MCORE2 || MK7 || MK8) ++ default "6" if X86_32 && (MPENTIUM4 || MPENTIUMM || MPENTIUMIII || MPENTIUMII || M686 || MVIAC3_2 || MVIAC7 || MEFFICEON || MATOM || MCORE2 || MK7 || MK8) + default "5" if X86_32 && X86_CMPXCHG64 + default "4" + diff --git a/queue-5.15/x86-mm-ident_map-use-gbpages-only-where-full-gb-page-should-be-mapped.patch b/queue-5.15/x86-mm-ident_map-use-gbpages-only-where-full-gb-page-should-be-mapped.patch new file mode 100644 index 00000000000..b5cc6a4a76d --- /dev/null +++ b/queue-5.15/x86-mm-ident_map-use-gbpages-only-where-full-gb-page-should-be-mapped.patch @@ -0,0 +1,77 @@ +From d794734c9bbfe22f86686dc2909c25f5ffe1a572 Mon Sep 17 00:00:00 2001 +From: Steve Wahl +Date: Fri, 26 Jan 2024 10:48:41 -0600 +Subject: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. + +From: Steve Wahl + +commit d794734c9bbfe22f86686dc2909c25f5ffe1a572 upstream. + +When ident_pud_init() uses only gbpages to create identity maps, large +ranges of addresses not actually requested can be included in the +resulting table; a 4K request will map a full GB. On UV systems, this +ends up including regions that will cause hardware to halt the system +if accessed (these are marked "reserved" by BIOS). Even processor +speculation into these regions is enough to trigger the system halt. + +Only use gbpages when map creation requests include the full GB page +of space. Fall back to using smaller 2M pages when only portions of a +GB page are included in the request. + +No attempt is made to coalesce mapping requests. If a request requires +a map entry at the 2M (pmd) level, subsequent mapping requests within +the same 1G region will also be at the pmd level, even if adjacent or +overlapping such requests could have been combined to map a full +gbpage. Existing usage starts with larger regions and then adds +smaller regions, so this should not have any great consequence. + +[ dhansen: fix up comment formatting, simplifty changelog ] + +Signed-off-by: Steve Wahl +Signed-off-by: Dave Hansen +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/all/20240126164841.170866-1-steve.wahl%40hpe.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/mm/ident_map.c | 23 ++++++++++++++++++----- + 1 file changed, 18 insertions(+), 5 deletions(-) + +--- a/arch/x86/mm/ident_map.c ++++ b/arch/x86/mm/ident_map.c +@@ -26,18 +26,31 @@ static int ident_pud_init(struct x86_map + for (; addr < end; addr = next) { + pud_t *pud = pud_page + pud_index(addr); + pmd_t *pmd; ++ bool use_gbpage; + + next = (addr & PUD_MASK) + PUD_SIZE; + if (next > end) + next = end; + +- if (info->direct_gbpages) { +- pud_t pudval; ++ /* if this is already a gbpage, this portion is already mapped */ ++ if (pud_large(*pud)) ++ continue; ++ ++ /* Is using a gbpage allowed? */ ++ use_gbpage = info->direct_gbpages; + +- if (pud_present(*pud)) +- continue; ++ /* Don't use gbpage if it maps more than the requested region. */ ++ /* at the begining: */ ++ use_gbpage &= ((addr & ~PUD_MASK) == 0); ++ /* ... or at the end: */ ++ use_gbpage &= ((next & ~PUD_MASK) == 0); ++ ++ /* Never overwrite existing mappings */ ++ use_gbpage &= !pud_present(*pud); ++ ++ if (use_gbpage) { ++ pud_t pudval; + +- addr &= PUD_MASK; + pudval = __pud((addr - info->offset) | info->page_flag); + set_pud(pud, pudval); + continue; -- 2.47.3